Brian Demers
Hey!
We have another post on using the @PreAuthorize annotation.
Is that what you are looking for?
vinh
Thanks for your answer.
The post you sent me is almost what I want except the role management.
Instead of managing roles in okta, how can I do that in the application?
For example, after the login workflow, the authenticated user has already “ROLE_USER”, I want to add “ROLE_MODERATOR” to the authenticated user. Is that possible?
vinh
I’ve just seen this.
https://github.com/okta/okt…
This is exactly my problem.
Brian Demers
That one is on our short list, and rapidly moving closer to the top 
vinh
Ok. Thank you
praveen kumar r
a) Hi… even after adding my default user to the Admin group, I am still not able to access the admin page.
b) Could you please elaborate on how okta communicates back to my localhost server about the newly added “group claim (Admin)”.
c) In the developer console I am not able to see any explicit “/token” calls being made, want to understand how the access token is communicated back to my localhost.
Matt Raible
When you add the groups claim to your authorization server, it gets added to the access token. Spring Security reads that access token and converts the groups into authorities.
praveen kumar r
Hi… I am still stuck with the same issue, I cant see an explicit “/token” call happening, were can I view my access token ?
I searched around a lot, but couldn’t figure out the exact difference between, “redirect_uri”, “callBack URL” and a “sso.loginpath” property, are they one and the same ?
Brian Demers
For basic OAuth/OIDC integration you need the “redirect_uri”, but to trouble shoot your token issue.
Can you take a screen shot of how you have your claims setup in your authorization server in the “claims” tab?
The quickest way to see what a token looks like is to look at the “token preview” tab for your Authorization Server.
From there you should see the “group” claim for your access token.
Keep us posted!
niraj rohit
Hi
Thank you so much for help.
could you please explain how we can authenticate by phone no or email id in spring boot. bec by default spring boot have authentication by username and password only,
1.is any way to do by pone no and password or email id and password?
2. otp authentication?
please explain.
Thanks in advance
Brian Demers
@nirajrohit
Usually the easiest (and safest) way to do that is to use OAuth. Your application doesn’t care how a user was authenticated. ON the IdP side (Okta for example) you would configure the login policy to allow specific factors.
The additional benefit is if you need to change how login is managed, none of your application code needs to change.
Does that help?
UchihaItachi1209
Hi Okta team,
I have been working with Okta as authorization server in my application. I added groups claim to the default auth server and able to see a list of groups the user is part of in the access token under the added claim at the resource server (Springboot app, 2.3.4.RELEASE, Spring Security 5.3.4). Next, I am unable to see the Role getting validated with below approaches:
1. Security config by modifying SecurityWebFilterChain bean to include both Scope and Role based check in ServerHttpSecurity. The security config is already having Scope based authorization working. Tried with hasAuthority, hasRole:
http.authorizeExchange()
.pathMatchers("/api/ast/projects/**").hasAuthority(“SCOPE_project.read”)
.pathMatchers( “/api/ast/projects” ).hasRole( “ROLE_ASTLead” )
.anyExchange().authenticated()
.and()
.oauth2ResourceServer()
.jwt();
2. Enabling @EnableGlobalMethodSecurity(prePostEnabled = true) and using @PreAuthorize as given in this article or directly on the method at controller. Here I am required to add “spring-security-oauth2-autoconfigure” dependency to be able to access EnableGlobalMethodSecurity annotation. As per Spring Security 5’s this is a bridge between old OAuth and new (OAuth2.0), so not sure if this is really the right approach now.
Appreciate some guidance here in achieving Role Based Authorization wrt Spring Security 5’s. Sorry for being more verbose!