Our organization is using Okta for our single sign-on solution (of course). Users need to be restricted to viewing their own account information. For example, if a user’s account is 123456, I want them to only be allowed to view data associated with account 123456. They should not be able to view account 98765 (and so on).
What is the best way to tackle this with Okta? Should I enhance the token with the desired account number? Should I create dynamic scopes? Any guidance or best practice here would be appreciated. I will be utilizing Java/Groovy and the Spring Framework. Thanks!
users do not see each other data in Okta. If you are talking about your application, then token should contain the data about the user, so in your application you can limit your data to only those ones belonging to a user. That’s what id_token is for
It sounds like you want to protect resources for your application based on the account a user is associated with. If this account number is available in their Okta user profile, you could create a custom claim to contain this information in a user’s access token and your resource server could determine what roles they are granted based on it, similar to whats done in this blog post.
Thanks, @phi1ipp and @andrea! I think that is probably the best way to proceed. The user could potentially have multiple accounts. What would be the best way to dynamically add claims to an Okta user? For example, they may open and close accounts with us any time.
Ideally, we would have the user log into our Okta customer tenant, and then the JWT is passed back to the client application. Somewhere in between, however, we would fetch their list of accounts and ideally put them into the token. Would it better to utilize a post-login hook to perform this? Or is there a better way?
You may want to look into using Token Inline Hooks. That way, before your application/user is issued tokens, the inline hook can be triggered and you can configure your endpoint to call whatever api endpoint has this account list and then store it directly in the token claims.
Thanks @andrea – this looks pretty cool. Is there any way to secure the inline hook call by requesting a token from another authorization server? I’m not keen on the idea of hard-coding my authorization header, but maybe it really isn’t an issue.
I just checked with product and this is not supported at this time but it is something we are looking to add for all hooks in the future. Here’s a feature request I found in our Ideas portal that can help us track use cases and the level of interest to get this added to our roadmap.
Thanks, @andrea. I’ll keep an eye on that in the future. What are your thoughts on hard-coding the Authorization header? There are some strategies we could employ to secure the target endpoint… but it still feels wrong.
I haven’t personally used it in a production environment, but I definitely understand your concern about having a static auth header like this. Something you could maybe do is rotate the key on your end (expire/revoke the old one and create a new one) and then update the inline hook config when you do so. You could use the API endpoint for hooks to make this call automatically if you do do something like this.
Cool. Learning a lot about Okta just from this conversation alone. I will pass this info on to others in our organization. I also considered using the Okta API to update account numbers on the user’s profile, which might be another good option Thanks for the information, @andrea!