How does an OpenID Provider authenticates an end-user?

1
votes

OpenID Connect 1.0 enables Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server and provides claims in exchange for an access token. The access token is provided to /user_info or /me endpoint to get the requested claims in return.

The section 3.1.2.3 of OpenID Connect 1.0 spec explains the process of authenticating an end-user. However, it clearly states

The methods used by the Authorization Server to Authenticate the End-User (e.g. username and password, session cookies, etc.) are beyond the scope of this specification.

The implementation of these methods is precisely my question. Plus, the OAuth2.0 specification doesn't provide any info on the implementation as well.

The doubts I've is how do we authenticate an end-user? The probable cases I could think of are:

  1. We keep some user's data like its profile info, username, password on Authorization server and other user-related information on the Resource Server.
  2. We keep everything on the Resource server and validate the user's credentials by sending a POST request along with user's credentials to an internal rest API on the resource server.
  3. Authorization and Resource server share the same DB instance, and hence no API calls.

I know the implementation will differ from one OpenID Provider to others but I want to know if these are even approaches that any OpenID Provider follows?

In some cases, the authorization and resource server can be the same, in which case sharing the database instance will become easy. But what happens in case of the servers being two different machines.

Let's say if I'm trying to write my own implementation of OpenId Connect. What suggestions would you give me to authenticate the end-users?

I tried to go through the codebase of node-oidc-provider library but the library doesn't authenticate the user and skips that part. It'd be of great help if anyone could provide any pointers on this. What should be the best practice? What methods any other OpenID Provider is using?

1
oauth-2.0openid-connectopenid-provider
As you had already gathered, user authentication is completely out of scope for OpenID Connect or OAuth. So you can basically do it however you want. – Robby Cornelissen
This is exactly what I'm asking. How can I do it? What are the best practices? What things do I need to keep into consideration while implementing it? – Kartik Chauhan
Well, since it has nothing to do with OpenID Connect or OAuth, your question basically becomes "How do I authenticate a user?", which is a little broad. One thing though: implementing authentication on the resource server completely defeats the purpose of using OpenID Connect. – Robby Cornelissen
So that cancels out the second point which is to authenticate at Resource Server using REST API. – Kartik Chauhan

1 Answers

1
votes

As you can see from the helpful image, from the article about OpenId/OAuth 2.0 architecture from article by Takahiko Kawasaki @ Medium

Oid/oauth2.0 auth

There is a reason the authenetication mechanisms are explicitly stated to be out of scope, as authentication and its requirements are implemented by completely separate means. It can be done by absolutely any kind of authentication mechanism you choose, the only requirement is for authentication to implement proper responses to OpenID/OAuth requests.

Let's say you want to have a page authenticate against your Active Directory. All you have to do is extend existing Active Directory system with proper OAuth and OpenID plugins (assuming there are such), configure them, and after these protocols are available for authentication and authorization, you can specify your AD as OpenID/OAuth provider to whoever is prepared to accept them.

Back in early OpenID days, the first time sites such as LiveJournal allowed arbitrary OpenID providers to authenticate against, for testing the idea, I made a mock OpenID page on my hobby webserver, which just had enough OpenID support to authenticate the single user against the password I manually specified there. Worked all right, but would be probably quite an extreme example. These days it is easier to use Google OpenID connect or similar to have centralized profile management.

The question where to store authorization information is again quite nebulous, but it generally would make senses to be stored somewhere near the used authentication mechanism, as you are using this authentication mechanism to give authorization, so it makes sense that you keep track of what you have authorized using this particular authentication.

Note that OAuth is letting the authenticated user to be in driver seat, which is generally the case for public webapps.

In case of a non-public resource, it might frequently be the case that resource holders would only subscribe to OpenID or other federated identity provision, but would themselves decide which resources the user can access, based on where he comes from and/or who he is in the particular identity scheme.

An example would be university A library system, which might allow logins of university's B students, based on B's federated identity auth server, but not give them the same rights to A library as to its own students authenticade by universisty A authentication system.