CODEWITHSUNDEEP
oauth-2.0openid-connectokta
gbro3n
gbro3n

Reputation: 6967

OAuth Client Credentials Flow - having received and validated an access token, what is the best way to authorize based on token contents?

For context, I'm using the Okta SSO platform.

For machine to machine authentication, I'm using the Client Credentials Flow. Having received and validated an access token, I need to know how I should go about authorizing the request.

It seems I have the option of checking the client ID (in the "sub" claim) against an access control list.

Otherwise the options seem more complex, and possibly not secure, such as verifying the existence of a custom scope added into the access token.

What is the correct way to authorize the request based on the data I can get from the access token?

Upvotes: 0

Views: 746

Answers (2)

Gary Archer
Gary Archer

Reputation: 29293

The OAuth client id is a value such as 0ajiowefr789 and does only one thing, which is to identify the caller in technical terms. On the receiving side you then need to map this object to what it means in business terms.

A couple of examples below:

  • 0ajiowefr789 represents a calling application, and you need to look up that external app's rights in your app's data

  • 0ajiowefr789 represents a calling external company, and you need to look up that company's rights in your app's data

In either case I would aim to represent privileges as a Claims / Principal object - which could contain things like roles, read / write access to particular resources, or anything else you like.

class ApiClaims {
  clientId: string;
  callerName: string;
  callerType: string;
  readOnly: boolean;
  role: string;
}

Each API operation can then use the above data to enforce access to resources, and return 403 forbidden if the caller tries something they are not entitled to. Of course it makes sense for your API to allow callers only limited privileges - just enough to do what they need.

Upvotes: 1

anonymous
anonymous

Reputation: 4064

Client Credential Flow

MUST ONLY be adopted when you have absolute confidence that the target clients are 100% trustful entities for your protected resources or services. Because your authorization server is going to issue directly an access token for a registered client even with no authorization code provided. That's the beauty of the client credential flow.

The best way would be, as you mentioned, to check the client id prior to issueing an access token for the client. Sub value will be null in true client credential flow, because no end users are involved in the flow. It's just between registered clients and the authorization server.

Below is the client credential flow specified in RFC 6749. I guess you already know all of these stuff but just want to make sure what you think is the right approach or not.

+---------+                                  +---------------+

|         |                                  |               |
|         |>--(A)- Client Authentication --->| Authorization |
| Client  |                                  |     Server    |
|         |<--(B)---- Access Token ---------<|               |
|         |                                  |               |
+---------+                                  +---------------+

           Figure 6: Client Credentials Flow

If you can absolutely trust your client, then there's nothing to authenticate it. Otherwise choosing client credential flow could be possibly a wrong choice that can result in jeopardizing your protected resources.

Upvotes: 2

Related Questions