OIDC Identity Provider design for SSO: should third party website handle authorization on their own?-CodePudding

Let's say I'd like to develop my own OpenID Connect Identity Provider to let different website add a Single Sign On button to their login pages.
For example, WEB A and WEB B can connect to MyIDP to start the single sign on.

WEB B starts the OIDC flow. After user authentication on MyIDP and granting authorization over MyIDP frontend, user is redirected to WEB B with id_token (containing user info) and the access_token.
WEB B can now log in the user using the id_token. Same thing applies for WEB A.

Now let's say that WEB A and WEB B has some functionalities which are restricted base on roles... for example WEB A backend APIs require roles manager and user and WEB B backend APIs require role consultant. So each website has its own real/domain role.

My question is:
should my OIDC Identity Provider MyIDP issue an access_token with these specific roles, so MyIDP should always acknowledge each third party website and all of the possible roles (store them in the database and let websites ask for them)? Is this why the OIDC protocol expects an access_token to be generated?
Or is the access_token specifically related to endpoints on the MyIDP itself and each platform should handle their own roles for the new user?

CodePudding user response：

It depends whether the applications want to use your IDP only to authenticate users, or also to authorize them.

In the first case, the apps manage their users separately and only use the SSO of your IDP to authenticate the user. E.g. WEB A will log in user1 and will get an ID token for that user. It will then create an account for user1 and assign some roles. This information will then be used to access WEB A's backend.

In the second case, when you want to use your IDP also for authorization, the IDP issues both an ID token and an access token, and that access token is used to access any backends. This will mean that the party that is in control of the IDP is also in control of the backend services that web applications A and B will call. The web app then requests certain scope from the IDP and the user can consent whether to grant that scope.

So it can be both ways — it depends on the architecture that you want to use.