CODEWITHSUNDEEP
authorizationopenid-connect
PhotonTamer
PhotonTamer

Reputation: 1137

Adding authorization to OpenID connect

I'm designing a microservice system including authentication and authorization. I understand the authentication part using OpenID connect, but I wonder how authorization enters the picture.

Let's assume the following situation: We have a user sitting at his browser connecting to a web application ("client" or "relying party"). First he logs in to the client, then he want's to access (via the client) an order service. However, not every user is allowed to view the orders, e.g. only employees from sales department are allowed to view orders.

For the process of logging in, the user, the relying party (RP) and an identity provider talk OpenID connect. At the end, the RP has an id token identifying the user.

Now, when accessing the order service, some component has to check the user rights. Where is this component located? Does the RP ask for the rights before querying the order service? Does the order service ask the user rights? Which information/tokens are sent to the order service and the "authorization component"?

I've seen access tokens in OpenID connect as well, but as far as I understand, these are OAuth2 tokens which state that a resource owner has delegated his access rights to a client. However, this does not apply to my problem where I don't have a resource owner, but rather want to check if the user is allowed to view orders. This is probably not part of OpenID connect, but it seems a standard problem to me, although I could not find any examples for it.

In case it helps: I'm using ASP .NET core and IdentityServer4 for authentication and the IdProvider is part of my system (no third party log in). If other protocols are better adapted to this problem, I'm glad to learn about them!

Upvotes: 2

Views: 2367

Answers (2)

jwilleke
jwilleke

Reputation: 10986

Within openID connect (and OAuth) Scopes are used for determining "Roles" (Authorization) by the RP.

The authorization server MAY fully or partially ignore the scope requested by the client, based on the authorization server policy or the resource owner's instructions.

As an example: An application may have some Resources that are publicly available for any Authenticated Resource Owner that is also a customer.

When the Resource Owner is utilizing Social Login the Authorization Server may determine this user is also a Customer. The Authorization Policy says that any Customer may be granted the "read_premium" OAuth Scope. So the Authorization Server would grant the Privileged Scope "read_premium".

Upvotes: 0

paulsm4
paulsm4

Reputation: 121649

You are correct.

"Authentication" (e.g. the IDServer4 implementation of OpenID) is a mechanism for verifying you are who you say you are.

"Authorization" determines what privileges the authorized user may be granted. They're two different things.

"Authorization" is an "application level thing". Your APP determines:

a) what roles exist,

b) how authenticated users are assigned to a role

c) what privileges are granted depending on the role.

For "Enterprise apps", a "Directory Service" (for example, MS Active Directory) is often used to map users to roles. Other times, the application does the mapping itself.

In other words, once you've established a user's identity, there are many, many different ways to assign "privileges". The best I can suggest is to think in terms of some kind of "Role Based Access Control" (RBAC).

For example:

Upvotes: 0

Related Questions