Outsource user managment via OpenID Connect for a web application

Question

I'm trying to get my head around OAuth 2.0 and OpenID Connect. The main question is if this is a useful approach to outsource user management for a web application. I tried to summarize how I understood the infos I found:

The idea is to use OpenID Connect with a custom enterprise identity provider (not Google/Apple/Microsoft/...). So all blue boxes belong together to "one" web application and only the identity provider (IDP) is external.

Some remarks to my graphic:

• The authorizaton server is also the OpenID Provider (OP), which is issuing id_token and a custom/extended access_token
• The client is redirected to the login page of the IDP for authorization
• There is no (real) need for asking permission to access the ressources (APIs) as shown in all OAuth examples. The web application has it's own permission and licensing handling. I only need the authentication part (OpenID).

Are these assumptions correct? Then I have some additional question to OIDC:

1. What do I have to store on my site? Do I need to store the sessions in my database? What about users? Especially in the case the user account gets deleted, deactivated, renamed ...
2. How does the communication between OP and IDP does look like? What protocol is used (SAML, ...)?
3. Is this perhaps a too complex scenario and another approach should be used? Which one?

Answer 1

You have identified all of the roles correctly:

• On your site you would store business data, but no user credentials. It is also possible to store the personal data / GDPR fields in the authorization server. You need a way to link users together, as discussed in my blog post.

• The connection between OP and IDP can use any standards based protocol, eg SAML. More commonly these days your app runs an OIDC code flow to the OP, which then runs another OIDC code flow to the IDP. The authorization server can enable other ways to login though, eg WebAuthn or mobile wallet integration.

• The separated approach is more commonly used in conjuction with APIs that use access tokens for their business authorization. This enables data access to many types of client in addition to browsers, eg mobile, B2B.

In OAuth you avoid coding authentication directly into the app. It is a clean architecture, yet there is a cost to migrating users to this type of setup, getting stakeholder backing, and finding an authorization server that meets your requirements. So choose the right time for it.

A shorter term, and less elegant, alternative might therefore be to break the rule and integrate a connection with the IDP directly into your web app. In this case you will not be able to control the contents of tokens issued, or use other forms of authentication though.