I’m a newbie to OAuth2 protocols and wanted to check a few things that’s still unclear to me.
We have a service (let’s call it ABC5 for now) supporting basic and LDAP authentications. If we add OAuth2 to these for SSO, how could we configure group and authorization information to be granted and included in the OAuth2 tokens?
I’ve checked the documents on your website and learned that we need a server config for the OAuth2 IDP(issuer, auth url, client id/secret). Then we could let our users use their IDP’s credentials when we generate an authorization url from the config. ABC5 will parse the incoming JWT tokens and create/manage a new user account in ABC5 server to keep track of the user behavior internally as we do for LDAP users. In LDAP, admin would add some groups in ABC5 side by looking at the LDAP domain’s group list and configure the privileges individually. When we move to OAuth2, how we do the same procedures? Should ABC5 call a rest api to retrieve group list from IDP and the IDP pulls privilege settings from ABC5?
I understand the group name for the user can be included in claims and ABC5 could parse it from access token. But what about the privileges? Let’s say there’s 4 privileges on ABC5 (grant, read, write, delete) and I want to have it appeared on the OAuth2 grant page after signing in. My specific questions are:
- Could the ‘scope’ parameter be used to set the 4 privileges of ABC5? Is this standard?
- If so, how scopes be dynamically managed as opposed to a static configuration at IDP? If ABC5 changes the privilege name ‘read’ to ‘access’, could that be automatically applied to IDP side too? And what’s the opposite direction for group info? (ie. send group info of IDP to ABC5)
- Can the IDP configure when & which user is allowed for privilege ‘write’? For example, IDP was allowing to ask scope ‘write’ but it’s now disabled so ‘write’ would NOT be displayed&assigned for new users although ‘write’ was included in the authorization url. And/or IDP can prohibit ‘write’ scope to those of ‘reader’ group.
Can you let me know if above approach is doable and is the standard way to control the authorization parts according to OAuth2’s RFC spec?