I’m currently using a setup where I set my audience to my custom API and specify ‘openid’ in the scope so I can get multiple audiences (i need access to /userinfo) (documented feature Get Access Tokens : Multiple Audiences) and this works fine. However, when I use the social login any other extra scopes (custom permissions for my API) are stripped away (ex: requested ‘openid profile email read:posts’ and got back ‘openid profile email’; read:posts is defined permission in my custom API). I’m not sure why :\ I need some help figuring this one out.
This should then add all permissions for the user in the access token even if the authentication is performed at an external provider. A couple of caveats though:
Including permissions in the Access Token allows you to make minimal calls to retrieve permissions, but increases token size.
Remember that any configured rules run after the RBAC-based authorisation decisions are made, so they may override default behaviour.
The user clicks the login/sign-up button and is redirected to the Auth0 login/register flow.
The user picks a social login method and is redirected to that provider to continue with authentication.
Auth0 does it’s magic here.
The user is redirected to the callback url with the code that is exchanged for an access token that has the scope of openid, email, profile, read:posts (custom permission) and the audience of my API and also the /userinfo endpoint. (this is a documented feature, check my initial post).
The app makes requests to the backend API with this token and also to the /userinfo endpoint.
This flow works without a problem when the social login is replaced by a simple email/password login. I think what’s happening is that the social login considers “read:posts” to be a provider specific permission and does not check for a custom API permission.
Here is an example of the decoded auth token with and without social login:
The step I thought you were doing was to assign the permission to the user before requesting the read:posts scope. Authenticating via Google without this permission being assigned to the user and RBAC being enabled wouldn’t return this scope as Google has no knowledge of it and it’s not applicable to Google.
You’re actually on the right lines with your last post! My suggestion would be to create a default role with the required permission(s) to your API, then use a rule to add the default role to the user on first login, by calling the management API:
There is an example rule here:
This will need to be done in a rule rather than the Post Registration Hook as the Post-User Registration extensibility point is only available for Database Connections and Passwordless Connections.
@andy.carter i’ve tried that rule and actually managed to add the “default” role to my users on the first login… my only problem now is that this seems to happen async, so it would first prompt my user to grant access to profile and email and by the time my callback is called and i have any chance to exchange the code for the token, the role will be added and i will be blocked by a consent_required error (because the scope has changed in the meantime) and so, on the second login attempt i am prompted with the new permissions request (ex: for “read:posts”) and after that it all works ok.
This flow is not desired… is there another way to add this role, or to maybe make the rule pause the authentication until the role is added?
Thanks a lot! Your help was very useful.
//Laurentiu.
