Method Security with Spring Security and PreAuthorize
In this tutorial, you’ll secure a Spring Boot app with Spring Security and the PreAuthorize annotation.
Vladimir SD
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
Matt Raible
I wrote about how to do front-channel logout with Spring Boot and Angular last year. https://developer.okta.com/…
Brian Demers
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!
Vladimir SD
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
Matt Raible
No, as far as I know there is no Postman collection for logout.
Vladimir SD
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
@PreAuthorize(“hasAuthority(‘ROLE_Foo’)”)
and as a boolean check inside a method :
if(request.isUserInRole(“ROLE_Foo”))
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.
Brian Demers
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
@PreAuthorize(“hasAuthority(‘ROLE_Foo’)”)
or
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?
Vladimir SD
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.
Brian Demers
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 hasRole())
This is probably a deep topic all on it’s own 
Konrad Banyś
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?
Konrad Banyś
it seems to work in 1.2.1 but not so in 1.3.0…
Matt Raible
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!
Rafif elfazri
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?
Matt Raible
Hello Rafif,
It’s probably because your “groups” claim isn’t configured correctly. See the screenshot in this tutorial to see what it should look like.
Rafif elfazri
This is my screenshot of my groups claim, it still doesn’t show it on when I access/user/oauthinfo
Rafif elfazri
I tried to fill ‘Include In token type’ with access token and it still not work.
Brian Demers
Hi Rafif!
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 id_token and token (the latter is the access token)
Keep us posted!
Rafif elfazri
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.