As the creator of an API ecosystem with OAuth, you want to allow access to your APIs via scopes that can be attached to an access token. My questions are thus:
How do YOU define a scope?
Would you expect any scopes you define to provide access only to resources/methods within a single API, or should a scope include access across multiple APIs?
How likely are you to define scopes in an API definition file like Swagger/OAS or RAML vs. within some sort of API gateway tool?
Should scopes be defined outside of the context of a specific API as part of a separate OAuth management tool, alongside things like IdP registration and client application creation?
I realize there may be several possible answers and perspectives on this - that is exactly what I am looking for.
Thanks for your help!
My OAuth2 server has the ability to create arbitrary scopes. Scopes are similar to 'roles', they describe groups of functionality.
The OAuth2 server is essentially unaware of what theses scopes are. API Resource servers receive Bearer tokens, and based on the bearer tokens find out what scopes are associated with it, and make decisions on what a user can and cannot do with that scope, but to the OAuth2 server, they are opaque strings.
We don't use swagger/RAML.
Related
I'm trying to wrap my head around scopes for this scenario.
I have a SPA client and an API. The client only communicates with this API and the API has no other clients communicating with it.
The application has two access levels, say a user and an admin (the SPA may block some routes for the user and the API may block some endpoints).
The roles are administered with AD-groups and mapped to the roles claim.
So what role does scopes play in this scenario? I do all authorization based on the roles claim. But I still need to specify a scope, so I have a API://[clientid]/all scope. Could someone help me make sense of all this?
Scopes are fixed at design time. They are high level privileges that indicate an area of data and what you can do with that data. These are often used as sanity checks, eg to prevent tokens for a valid user but wrong app being used to call an API.
orders_read
Claims are dynamic values looked up at runtime, and tend to have different values for different users. Pretty much all real world authorization is based on claims:
role = supervisor
company_id = 407
So in your case just define a scope or two, but keep them high level and easy to manage. Your claims based authorization (using roles) seems fine.
FURTHER INFO
At Curity we have a couple of good docs that explain the science of designing authorization based on OAuth standards:
Scope Best Practices
Claims Best Practices
I have an application which provides authenticated users with views into data about various objects in a database. There's another application in our ecosystem that provides different views into some of the same objects, using its own permission model. We trust that other application's permission model, and would like to allow them to issue access tokens to users who haven't been authenticated through our application's usual method, so those users can only view specific objects that the other application has verified they have access to.
Rather than coming up with our own spec for the communication between these two applications, I was wondering if there's already a standard approach available via something like OpenID Connect. OIDC seems to handle most of the gnarly details we'd have to consider in a case like this, but the one aspect where it doesn't seem to fit is that its access tokens seem to be general-purpose, rather than calling out a specific object that the user has access to. It says "Here's a user who can access your application", but not "Here's a user who can access Item 123".
Is there a standard for using an access token to grant access to a specific item, preferably using OAuth 2 and/or OpenID Connect? Am I correct in assuming that using an item's ID as a scope on the access token would be an inappropriate use of OAuth scopes?
I've always found the best design for most real world apps to be like this:
OAuth 2.0 based tech identifies the user
You then lookup user details at an application level to enforce authorization
OAuth 2.0 scopes etc cannot handle things like this:
You don't have access to account 123
You don't have access to region US
So I tend to look them up from the user id in the token after login. This tends also to be much easier to extend, if for example the items and user rights in the external app grows over time.
For more concrete info see my write up on API Claims Caching.
Also here is an example of the coded algorithm in a Rest API, resulting in a claims object that can be injected into logic classes.
In your case the custom claims provider would be the external app, and you could query claims from it, for data that does not really fit well into OAuth tokens.
Just my thoughts - not sure if it will fully work for you - but I've found this to be quite an adaptable solution, which often puts responsibilities in the right places.
OAuth 2.0 protocol provides permissions delegation of a user so that third-party apps can operate on its behalf. A typical way this is done on the OAuth flow is requesting a user consent to either approve or deny access for the app (Okta example). Here is an official spec describing how it works in general concepts.
I'm looking for the standardized approach to perform the same flow but for the user groups (e.g. organizations). GitHub does that in some way for organizations, so it looks like organizations represent just a group of user accounts. Are there any standardized approaches to this problem?
If not maybe there are any recommended ways how its typically done architecturally or can fit into OAuth 2.0/OpenID Connect protocols.
The OAuth 2.0/OpenID Connect protocols do not cover how access control is performed.
You can, within the OAuth 2.0/OpenID Connect protocols, pass OAuth Scopes or use the OIDC user info endpoint data to allow the resource server to make determination for Access Control.
Many of the commercial products within this area allow the use of LDAP as a back-end for authentication and will even convert LDAP Groups to Scopes.
I would assume, but I do not know, that GtHub stores data with a link (like a group) for the on Organization and/or the user. I know GitHub exposes this using OAuth Scopes.
Oh, and the OAuth Spec is at: https://oauth.net/2/
But if you require Authentication of users then you need to be using OpenID Connect which is built on-top of OAuth 2.0.
Remember that "OAuth 2.0 is NOT an Authentication protocol"
-jim
There are limits to what you can show on the consent screen and dynamically calculated data is not usually supported.
You ought to be able to express a high level scope that you can present to the user though.
In terms of authorizing based on a user's organisations the claims caching technique here can be useful:
https://authguidance.com/2017/10/03/api-tokens-claims/
That is:
* Use OAuth for user identification and high level checks
" Then do the real Authorization based on your back end data
I'm making some assumptions here, but I believe the issue arises from trying to authenticate two things at once.
If the organization is what you need, then go ahead and create a flow to authenticate the organization as the principal subject (via a user who has access to it), instead of actually authenticating the user itself.
Once the access token is generated, you do not necessarily need to know which user generated it anymore (or at least, the token itself does not need to know). If your user needs to be able to view and/or revoke access tokens, they should still be able to do that, since they have access to the organization in your app.
I've been using Oauth2 for quite some time as a developer but still feel at times I need to go back to the basics. I have a general question around this topic, specifically when it comes to using scopes.
As I understand, scopes are a kind of filter that can be applied to certain APIs and the bearer token is required to possess any scope the API requires. In that sense, they offer an extra 'layer' of protection after the token itself. However, what I would like some feedback on is how best to protect an API that requires scopes. If a consumer obtains a valid bearer token from the issuer and discovers what scope is required for a service, what's the best way to prevent them from making a POST using a token obtained through client_credentials, for example, on a restricted resource?
I believe I know a few solutions: require some sort of user token as well and further lock down resources via a authorization in your business logic (e.g. customers can only modify their own data). Another option might be to require api registration and an approval workflow so only 'approved' clients can invoke a service. Similar to how Akana and other API Gateway products operate. But are there other things I'm missing? Are Scopes really meant to serve as an authorization mechanism at all, or am I misinterpreting their real purpose, because to me they don't seem like they offer much.
Thanks for feedback in advance.
Does OpenId support a two way exchange of tokens at any place in the spec? Specifically allowing both parties to share tokens with each other in some way so they can share services with each other?
I've looked through the spec, but can't see anything detailing any scenarios like this.
An app I'm working on has integrated itself with a trusted OpenId provider, we'll call Acme.
We'd also like to provide access tokens and refresh tokens to Acme, as they'd like to access features of our service as well.
It seems natural that during our interactions to get tokens from Acme, that we'd like to expose tokens to them.
Is this part of the spec in any way? Or is the only way to do this is to become a full identity provider ourselves?
You could include the tokens as part of a request object, see: http://openid.net/specs/openid-connect-core-1_0.html#RequestObject but that would depend on a pair-wise agreement with Acme since they'd need to handle the non-standaridzed request object contents.
The best way forward is to become a provider yourself so you can leverage all the features of the various flows without being dependent on a pair-wise agreement and accompanying implementation.
It sounds like you're confusing OpenID Connect and plain OAuth2 to some extent.
OpenID Connect is a specification for identifying end users to a client application, based on their authentication at the OpenID Provider. It's not clear from your question whether end users are even part of the picture, so even plain OAuth2 may not be relevant (unless you are just using the "client credentials" grant).
Neither spec says anything about mutual exchange of tokens. It would probably help if you describe the interactions you anticipate in more detail and which grants you expect to use. Who will authenticate to your identity provider and what would be a typical client application?