In this tutorial, you’ll secure a Spring Boot app with Spring Security and the PreAuthorize annotation.
Excellent write up. I was considering going with Cognito before coming across this. With the sample code provided, how do I log the user out so that I can keep trying different logins? I’ve tried clearing the localhost cookie with inconsistent results.
Even with a new browser window if I hit the user/oauthinfo page I get the users info. Even a new Incognito browser window does not always work
I wrote about how to do front-channel logout with Spring Boot and Angular last year. https://developer.okta.com/…
What is likely happening is your applications session is ending, but your user is still logged into Okta (Single Sign On).
Spring is then redirecting you back to Okta (which then redirects back to your application).
The next version of Spring Security (5.2) will support RP Initiated Logout (which would clear your Okta Session as well), until then take a look at the link Matt posted!
Let us know how it goes!
Thanks Matt and Brian. One more question on Okta. Does the logout api have a postman collection.
I looked at https://developer.okta.com/… but it’s not part of OpenID Connect
No, as far as I know there is no Postman collection for logout.
I’m not clear on what this means from the article:
Roles in Spring are authorities that have the ROLE_ prefix (like all things in Spring, the prefix is configurable). One way to think about this is that roles are intended for large sets of permissions while authorities can be used for finer-grained control.
From what I can see we only have groups in Okta which mean that they become both Roles and authorities.
If we name the group starting with “ROLE_” then we can do Preauthorize on the method like
and as a boolean check inside a method :
Ideally, we would be able to create Roles and assign users to them and as we discover a need for finer grain permissions we would assign those permissions to the Role.
This is basically how AWS IAM works for permissions within AWS.
It’s been a while since I’ve tried to change the ROLE_ prefix, but here is a related SO post: https://stackoverflow.com/q…
If you name one of your Okta Groups
ROLE_Foo then it should work either way
request.isUserInRole(“Foo”) // NOTE i removed the “ROLE_” prefix
However if you have a group named simply
Bar you would NOT be able use this as a Role.
Does that answer your question?
Your explanation is exactly the behavior that I noticed too.
My confusion is with Andrew’s statement in the article :
"One way to think about this is that roles are intended for large sets of permissions while authorities can be used for finer-grained control."
I get the “roles” part. Was curious about the “finer-grained control” of authorities.
IMHO it’s partly conceptual. Roles are generally higher level, but authorities could be anything.
You could create new Authorities prefixed as PERMISSION_ and use them as permissions, used the oauth SCOPE_, or just use them treat them as strings. Lots of flexibility (vs using
This is probably a deep topic all on it’s own
what might be the reason that when I open the user/oauthinfo url, I see the groups im “groups” but not in “user authorities”? what did I do wrong?
it seems to work in 1.2.1 but not so in 1.3.0…
Can you please enter an issue for this in the Okta Spring Boot starter project and include steps to reproduce the problem. Thanks!
Ariel Alves Dutra
A huge article! Thank you very much!
I’m following your tutorials but my when i access /user/oauthinfo, it doesn’t show any groups attributes. What might be causing that issue?
It’s probably because your “groups” claim isn’t configured correctly. See the screenshot in this tutorial to see what it should look like.
This is my screenshot of my groups claim, it still doesn’t show it on when I access/user/oauthinfo
I tried to fill ‘Include In token type’ with access token and it still not work.
It should be “Access token” or you can define both types (and support a wider set of use-cases).
In your Okta console, under Authorization servers, there is another tab for "Token Preview"
Use the same configuration as you did for this example application.
NOTE: fill out the “scopes” as with: openid, email, profile, custom (you must press enter in between each one)
From there you can toggle between viewing the
token (the latter is the access token)
Keep us posted!
Thank you, it really solve my problem. I’m sorry for another question, I want to integrate your method of adding roles to app with this post :
This post allowed me to end the app session and okta session. I tried to integrate, it but it seems have a conflict between application.properties and application.yml.
The Problem is the groups doesn’t show on oauth.getAuthorities()
If there is any clue to solve this problem I really appreciated it.