feat: Federated Connections Support

[kishore7snehil]

Changes

• Added support for Federated Login for Authentication and Management APIs.

  • Extended the [/oauth/token (https://oktawiki.atlassian.net/wiki/spaces/AFG1/pages/3178596704/RFC+Federated+Connections+Access+Tokens+-+EA) to support federated login.
  • Two new endpoints added to Users.py i.e.
    • Get a List of All Token Sets
    • Revoking a token set

References

• Internal Reference

Testing

• This change adds test coverage

• This change has been tested on the latest version of the platform/language or why not

Contributor Checklist

• I agree to adhere to the Auth0 General Contribution Guidelines.
• I agree to uphold the Auth0 Code of Conduct.

[siacomuzzi]

Regarding auth0/authentication/get_token.py -> access_token_for_connection

response = self.get_token.access_token_for_connection(
    subject_token_type="urn:ietf:params:oauth:token-type:refresh_token",
    subject_token=subject_token,
    requested_token_type="http://auth0.com/oauth/token-type/federated-connection-access-token",
    connection=connection,
)

What's the reason to make subject_token_type and requested_token_type args mandatory? IMO they should be optional with a default value, like we are doing with grant_type.

cc @kishore7snehil

Also, you are missing the login_hint argument.

As a reference, see nextjs-auth0 lib implementation: https://github.com/auth0/nextjs-auth0/blob/dbfd5021dd70657926be142980022bfb99993298/src/server/auth-client.ts#L1045-L1057

[kishore7snehil]

@siacomuzzi I believe those two fields are required for the endpoint to work properly and I have not assigned the default value as there may be a chance of subject_token_type and requested_token_type values to differ for different use cases in future.

Regarding login hint, this wasn't mentioned as a mandatory field at the time of implementation but if we are sure today then I can add this field and release a patch version.

[siacomuzzi]

I have not assigned the default value as there may be a chance of subject_token_type and requested_token_type values to differ for different use cases in future.

Oh ok, we are not following this approach in other SDKs where those fields have a default value assigned, that's why I'm asking

Regarding login_hint, it's not mandatory, but it's an optional field supported by this grant type