Custom OAuth2 Authorization Server / Identity Provider

Question

I am currently trying to implement my own Authorization Server following the OAuth2 protocol PKCE flow, coupled with my own Identity Provider. The idea is to be able to reuse the same identity provider across multiple SPA. To get a clearer picture I decided to draw a UML sequence diagram. This diagram details the different steps involved in the authorization process but also the authentication.

OAuth2-PKCE-Flow - UML Sequence diagram

Behind the scene my idea was also to implement my own Identity Provider (IdP) to authenticate users. I still want to share some information about Authentication and session management server side. I am using a JWT Token based authentication system, meaning stateless. However, I want to be able to strongly log out users. To do that I am gonna use a refresh token that my Authorization Server will store in a Redis "session store" DB. The latter is then stateful. Regarding the Authentication itself, it's held by the IdP which will verify users credentials. The IdP hosts a login form (simply an HTML page that will be rendered). It's worth saying that, unlike the login form, the consent form is hosted by the Authorization server since the concept of "consent" is only related to authorization.

Here I come with my questions :

1. What do you think about the flow shown in the diagram? I would definitely appreciate any feedback

2. I've tried to understand the concepts of Identity Provider and Authorization Server and how they interact with each other. I am not exactly sure who is supposed to generate the tokens (access and refresh). I would say it's the job of the Identity Provider since token is about authentication? If so, it would mean that the part of my diagram targeting the request/creation of the token is incorrect : Authorization Server would have to request the token from the Identity Provider, whereas now it's the Authorization Server itself which generates the token.

3. I inspected some web application (google, github, stackoverflow) to see how they deal with their own authentication system. Let's use the example of Stackoverflow. When I choose to log in using my stackoverflow account I expect the application to communicate with the Identity Provider which will provide the login form. The login form that is used is the one from the web-application itself, which means no redirection - we stay put, which makes sense yes. Let's go further, imagine I want to use Stackoverflow as "social login" for my application. The Identity Server I would reach behind the Authorization Server to authenticate should be the same as the one reached earlier when authenticating from Stackoverflow. I am wondering what concretely an Identity Provider is. Can it be that the client application itself plays as Identity Provider (since it hosts the login form)? Or is it just an API that provides endpoints for authenticating and generating tokens?

Even though I think I've got it what the concept of OAuth2 is, as you can see the concept of Identity Provider coupled with the Authorization Server is a little confusing to me.

Btw, I didn't mention that I am implementing all of that in Go.

Thanks for your help!

Answer 1

Bit of basics: Authorization: (Check if user A has access to resource Z). Authentication: check if the user who claims being A is really A.

OAuth2 is not an authentication protocol

From the oauth.net site:

The OAuth 2.0 specification defines a delegation protocol that is useful for conveying authorization decisions across a network of web-enabled applications and APIs. OAuth is used in a wide variety of applications, including providing mechanisms for user authentication. This has led many developers and API providers to incorrectly conclude that OAuth is itself an authentication protocol and to mistakenly use it as such.

OAuth2 describes how a third party application can request authorization to access a protected resource on behalf of a user. When the RFC6749 talks about authentication, is not authentication of the user, but the client application making requests to the authorization server.

Now, you didn't mentioned it but there's OpenId Connect, which is a

simple identity layer on top of the OAuth 2.0 protocol. spec

The IdentityProvider is a concept introduced by OpenId Connect, and its not present on the OAuth 2.0 authorization framework.

Most of the time the Authorization Server and the Identity Provider are the same application, implementing both oauth2.0 and OpenId Connect specifications, and refered as the OpenId Provider or simply OP. An OP is a OAuth 2.0 Authorization Server that is capable of Authenticating the End-User and providing Claims to a Relying Party about the Authentication event and the End-User.

Questions

1 What do you think about the flow shown in the diagram? I would definitely appreciate any feedback

I think its quite good but, I don't really get why you segregate the Authorization Server from the Identity provider and I don't know how you will be able to create the session cookie from one application to the other. But, if you solve this in a secure way (which I'm not sure is possible) then its fine.

2 I've tried to understand the concepts of Identity Provider and Authorization Server and how they interact with each other. I am not exactly sure who is supposed to generate the tokens (access and refresh). I would say it's the job of the Identity Provider since token is about authentication? If so, it would mean that the part of my diagram targeting the request/creation of the token is incorrect : Authorization Server would have to request the token from the Identity Provider, whereas now it's the Authorization Server itself which generates the token.

I hope that by now you know the answer. It's the authorization server who's in charge of creating access_tokens, because at first access_tokens where like door keys, they just grant you authorized access to a protected resouce. Thing is that with OpendId Connect an access_token includes claims about the user and also the means of how the user authenticated to the IDP.

3 I inspected some web application (google, github, stackoverflow) to see how they deal with their own authentication system. Let's use the example of Stackoverflow. When I choose to log in using my stackoverflow account I expect the application to communicate with the Identity Provider which will provide the login form. The login form that is used is the one from the web-application itself, which means no redirection - we stay put, which makes sense yes. Let's go further, imagine I want to use Stackoverflow as "social login" for my application. The Identity Server I would reach behind the Authorization Server to authenticate should be the same as the one reached earlier when authenticating from Stackoverflow. I am wondering what concretely an Identity Provider is. Can it be that the client application itself plays as Identity Provider (since it hosts the login form)? Or is it just an API that provides endpoints for authenticating and generating tokens?

Maybe, StackOverflow knows. Keep in mind that there's a lot of authorization systems out there relying on Json Web Tokens that are not OAuth2.0. I'm not saying that's the case, but maybe.

On a final note Identity Server is an implementation of an OpenId Connect Provider (OP) in .Net (and netcore) by Brock Allen and Dominick Baier who choosed this name and added a little bit more of confusion to the mix!