Great article. But I curious asking is the Scope is same with Security role? If same which one you prefer put all the sec-role in the OAuth or built in by yourself in the application?
30+ years of tech, retired from an identity intelligence company, now part-time with an insurance broker.
Dev community mod - mostly light gardening & weeding out spam :)
In the access token itself, these are the same thing. How an application understands the token content and uses it is different for each app.
For example - we have an application that handles workflow profiles (think Jira ticket lifecycle) on a per-user basis. Some people can edit profiles, others can execute. The app needs to know who you are, so you get the right profile, and we use the scope to determine if you can edit or execute. What we don't do is try and put the whole profile into OAuth properties. Note that OAuth and the authentication system does not understand profiles at all, it simple associates the words 'edit' and 'execute' with user identities, the application applies meaning to those terms locally.
Because what I think when we put scope in OAuth. It means that everytime we define scope: create_user, read_user, update_user, delete_user (let's say we have big module). We need to retrieve from OAuth to process all that information which is not efficient.
I always thinking that OAuth only need to be use for getting the token and refresh token. While security role is defined in the application it self to process the business logi..
30+ years of tech, retired from an identity intelligence company, now part-time with an insurance broker.
Dev community mod - mostly light gardening & weeding out spam :)
In our case, we have a need to share roles across a number of endpoints / APIs / applications in a single-sign-on environment. These roles are managed centrally through OAuth tokens. What the roles /mean/ when a specific application or endpoint receives them is defined locally (as I described in the example above).
If you have a single application, and it already has local permissions / role management capability, then you have little need to move that elsewhere. Indeed your driver for using OAuth is likely different too, typically such applications need to accept identity assertions from other environments such as Google or Facebook, whereas we are building an SSO platform for ourselves... YMMV!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Great article. But I curious asking is the Scope is same with Security role? If same which one you prefer put all the sec-role in the OAuth or built in by yourself in the application?
In the access token itself, these are the same thing. How an application understands the token content and uses it is different for each app.
For example - we have an application that handles workflow profiles (think Jira ticket lifecycle) on a per-user basis. Some people can edit profiles, others can execute. The app needs to know who you are, so you get the right profile, and we use the scope to determine if you can edit or execute. What we don't do is try and put the whole profile into OAuth properties. Note that OAuth and the authentication system does not understand profiles at all, it simple associates the words 'edit' and 'execute' with user identities, the application applies meaning to those terms locally.
Because what I think when we put scope in OAuth. It means that everytime we define scope: create_user, read_user, update_user, delete_user (let's say we have big module). We need to retrieve from OAuth to process all that information which is not efficient.
I always thinking that OAuth only need to be use for getting the token and refresh token. While security role is defined in the application it self to process the business logi..
As usual - it depends :)
In our case, we have a need to share roles across a number of endpoints / APIs / applications in a single-sign-on environment. These roles are managed centrally through OAuth tokens. What the roles /mean/ when a specific application or endpoint receives them is defined locally (as I described in the example above).
If you have a single application, and it already has local permissions / role management capability, then you have little need to move that elsewhere. Indeed your driver for using OAuth is likely different too, typically such applications need to accept identity assertions from other environments such as Google or Facebook, whereas we are building an SSO platform for ourselves... YMMV!