What are the most common ways to Architect the verification process of the access tokens between resource and authentication server using OAUTH 2.0?

Question

I'm trying to build a web application broken down into a bunch of micro services and each micro service is a resource server. I also have a separate authentication server.

I'm wondering which of the approaches below is better or if you think you have better idea or believe OAUTH is not the right tool for this.

Here are the ways I've tried:

• User (resource owner) goes to my app home page http://example.com
• This landing page has username and password field so once the user enters these fields I make an ajax call to the authentication server which eventually will give me an access token after the TWO-LEGGED OAUTH FLOW.
• Now I take the oauth access token and go to the resource server to access the resource.
• The resource server will now make another http call to the authentication server programmatically to verify the access token once the authentication server says yes then the resource server will serve request towards the completion (This way the resource server is totally isolated with the authentication process)

The other way would be to let the resource server verify the access token by talking to shared database.

Which one of these is the more common in the industry? Any other ideas on how to verify the access tokens?

Answer 1

OAuth2 is designed for authorization of third party clients to access protected resources on behalf of the owner of said resources.

1. It is not designed for authentication: you mention you use 2-legged auth in your flow, I assume you mean the client credentials flow or the Resource Owner Password Credentials Grant. Both are the wrong tool for the job, and since you already got the user's credentials I don't see why you can't authenticate them directly.
2. It is not for comunication between the resource provider and the authorization server: this aspect is deliberately out of scope in the spec:

The interaction between the authorization server and resource server is beyond the scope of this specification. The authorization server may be the same server as the resource server or a separate entity. A single authorization server may issue access tokens accepted by multiple resource servers.

This seem to be the two main points you're trying to solve, and none fits OAuth's use case.

You must understand that the goal of OAuth is to separate the roles of the client and the user. This is not the problem you're trying to solve.

Get a good grasp of the problem you need to solve and use the right tools for each job.

For authentication you can use OpenID Connect, Kerberos, some SAML based service, or setup your own authentication against a database with pkbdf hashed passwords.

For authorization there might be a place for OAuth in your solution, but there might be other options that work better on that environment. Don't fixate on the tool, focus on the problem at hand.