I am creating a simple spring based application using Auth0. The application is based on Spring security and web dependencies. I am able to register the application on Auth0 and using the Universal login with google as IDP provider able to authentication. The question i have i need to have custom scopes added to the access token . Please guide me on this aspect of modifying access token ( i have checked hooks but it is applicable for client credential flow ) . It will be great if you could point me to relevant documentation or steps for enriching the access token with custom scopes using spring security and auth0.
May be i am missing something . In addition here is what i am trying to do
I have created API ( APITest) where in i have added custom scopes ( permissions ) to it
I have created Web Application (WebTest) which has been given permission to the above API and i am invoking this application using Spring boot and security. ( Authorization Code Grant Flow)
3.In the application i have following snippet which is invoked when the authentication is successful
What my expectation was that i would be able to access both token ( identitytoken and access token ) using the clientRegistrationRepository. Unfortunately i am able to get identity token but not the access token.
When i invoke APITest application using the client credential flow , we are able to retrieve the access token.
I am sure i am missing something. As long as i am not able to retrieve the access token , any modification to it in the form of rules does not make sense.
Once the token has been generated, you should not be tampering with the scopes. You can add metadata, but tampering with the scopes takes away all the security benefits of this specific part of the flow.
On the other hand, you list accessTokem when the correct object is accessToken, and you are not namespacing your claims. Make sure that you follow the document step by step in order to achieve the intended results.
Hi
I did realized the typo about it and rectified it but seems to not to solve the issue. I do agree with you about not modifying the token once it has been generated and i do not intend do it in my final application. I went through this approach as the permission/scopes defined in the api where not being made available in the access token if i use the Authorization Code Grant flow. This seems to work perfectly well for Client Credential. I have set the audience attribute in the helper utility provided by Auth0 but still not luck.
Hope this provides you more data in helping you out.Sorry being persistent but need this solved quickly so as to make further decisions.
Then that’s a different issue Are you explicitly requesting the scopes, as listed in our documentation? Scopes
Just as you pass on the audience, you have to pass on the scope parameter, listing all of the scopes you want for that specific audience. These are not assumed because different parts of your application might require different scopes, and we have no way of knowing.
Give it a try and let me know if it works for you.
I have added a permission to my API under the permissions tab (XXXX:test) an in my actual api (in AWS) I have provided XXXX:test as a scope to the JWT verifier. Adding XXXX:test to my machine to machine client works well, tho when ever a user signs up (or logs in) the
a) user consent never shows XXXX:test
b) the returned scopes in the access token never have XXXX:test
I don’t really want to resort to hard coding a scope in a rule (I was not successful anyway) tho I can not for the life if me get the scope into my access token. Any pointers will be helpfull
Here is a request to auth0 pkce flow we are making
I have the exact same issue as @josephsk . It would be nice if we could get some feedback on this. It’s setup and working correctly for M2M, but not in client app flows.
I got the idea to start flipping the RBAC switches in the API’s settings. Ours were toggled on to begin with, after toggling them off the custom scopes come through just fine. We’re not using role-based permissions in the Auth0 layer so our use-case is safe to just disable. If you’re using roles I suppose you’ll have to set those up to play well with custom scopes.