Use OpenID Connect for authentication and custom authorization

Question

I'm working on a service where I want to protect endpoints from unauthorized access, but I don't want to deal with user management. This is how I found the OpenID Connect which I would like to use only as an identity layer. I'm a bit lost however with the authorization. For the authorization I want to have an application specific role based logic which would run on my server. I saw some examples for the authorization code flow, but in those examples the authentication and the authorization is done by the same server, which has authentication and authorization endpoint. Which also made me wondering, that how typical my use-case is. Maybe I shouldn't even do it.

It's not really clear to me, that what steps should I do when the authentication is done by the identity provider (i.e google), but the authorization should be done by another service. As I imagine in this case the flow would look something like this

1. Not authenticated user tries to reach a protected resource
2. The user redirected to the id provider's login page and it gets back the id token and an authorization code
3. Then the client should call the authorization endpoint with the authorization code to get access token.

In step 3 then I think I should have a connection to the identity provider in order to be able to validate the authorization code, right? What if there are multiple identity layers, how can the authorization logic decide then, that to which identity provider should it go?

Answer 1

The flow you are describing is exactly why OpenID Connect exists. It standardized a way to authenticate a user on top of OAuth2.0, which is simply an authorization protocol. That way you can simply do an identity check.

You're confused about the authorization part. What you want to do is not to separate the identity provider and the authorization with OpenID Connect itself, but rather use OpenID Connect only for the authentication part.

Pretending you're using Google to authenticate and that your own application handling authorization is called Melon, your flow would use 2 separate steps:

1. OpenID Connect: Perform the authentication with Google and receive user information (in form of an id token). At this point, you know that Google authenticated the user.

2. Melon: You now know that the user is authenticated and you have access to his information. You can now use your own authorization schemes to make sure the person can proceed with the request in your system. Of course, you need a way to associate the Google user to your system.