I am using the OAuth2.0 for authentication and authorization with the WSO2IS. I have multiple APIs on the ESB. There, the user may grant access to API1 and API2, but not to API3.
Is it possible to define custom scopes to limit the client from accessing all APIs?
If it is not possible, how do I protect the APIs from unauthorized access?
Side note: currently, I may only limit the access by defining different applications. However, this isn't suitable, because I must then manage multiple clientIDs and clientSecrets on the client side.
Yes.. you can define for that... by default, Identity Server does not validate any scope parameter before granting an access token. For that, you need to implement a new OAuth callback handler class according to your resource server. I guess this blog post explain it. However as i know, WSO2 Identity Server not provides access token based on the scope.. Access tokens are issued per client and resource owner. Not per client, resource owner and scope. This has been already discussed on wso2 public mailing list and it would be fixed for next release.
Related
From my understanding: -
The scopes that an oauth client can obtain are registered against the client on the Authorization Server .
The grant types that a client can use are registered against the client on the Authorization Server .
Resources are configured to allow requests containing access tokens that are associated with certain scopes.
Is there a mechanism in vanilla OAuth where the grant type in addition to the scopes are used when restricting an endpoint?
For example, given Client A with scopes=organizations, images and grant types=client credentials, auth code:
(at token creation)
For Client A to obtain an access token for ‘organizations’ scope, only client credentials grant type can be used.
For Client A to obtain an access token for ‘images’ scope, only auth code grant type can be used.
Or (when the resource endpoint it calls)
When the /organisation endpoint is called with an access token containing the expected ‘organization’ scope, only allow the request if the client credentials grant type was used to obtain the access token (fail if any other grant type was used).
When the /images endpoint is called with an access token for containing the expected ‘images’ scope, only allow the request if the auth code grant type was used to obtain the access token (fail if any other grant type was used).
As far as I know scopes are only limited by what is registered for a client.
The only way I can think of achieving the above would be to have two client registrations (e.g. b, c) for the same actual client (A) and configure client ‘b’ for client credentials grant type and organizations scope and client ‘c’ for auth code grant type and images scope.
Update
One option would be along OIDC lines to add a roles scope which would mean that the roles claims would be added to the access token. The access token could then be inspected to see whether the role is a third party (client credentials grant) or user (auth code grant).
I would still be interested to know if there is anything specifically built into oauth to restrict by grant type.
Tokens don't generally record grant information, and really the requirement is to be able to control access per application and based on the caller's rights.
I would always configure different OAuth Clients for different grant types - since these are different logical clients and can never share a session.
A few possible options:
OPTION 1. Use multiple APIs each with a different audience and configure different audiences for different OAuth Clients if that is supported by your Authorization Server
OPTION 2. An API endpoint can potentially check the client ID in access tokens against a list of allowed client IDs - though this is not a good long term option
OPTION 3. Use OAuth just to identify the caller and then look up rights for the caller that are stored and managed in your application data. This is almost always the best long term option.
OAuth only provides high level mechanisms for authorization and when you get into deeper domain specific authorization (eg what a role means or rules such as checking sufficient funds) it will not help you.
I like your idea of using roles, and from experience I would manage them like this:
Do high level OAuth authorization first via scopes etc
Identify the caller from the token's claims
Look up the caller's role(s) in your application data
Enforce the role's authorization rules in your API logic
I use WSO2IS as an OIDC provider for authentication and authorization. Using Authentication Code grant, I got the access-token. I need to authorize the users to access specific services based on their roles.
I tried to use XACML to solve this, but I found that I need to pass base64 encoding of username:password in the header of REST API XACML request. Instead is there any way I can authorize the user to access services based on their roles, using access-token ?
This part of authorization happens in the resource server. I thought I could use the introspection endpoint to authorize the user based on the access token using scopes. But I don't understand how scopes can be used to provide access control to the users ?
To get an access token with all scopes available to a user, the OAuth2 client must request all scopes it cares about and the token will contain only those that the user has access to. See this question.
Yes, it's cumbersome, but OAuth2 is primarily an authorization delegation protocol - it allows users to delegate some of their rights (scopes) to a client.
Alternatively, if you could decide permissions based on roles, you could probably get a list of user roles from an ID token.
I am using Identity Server 4 for authenticate user from a single application page. For the need of the project, I have to use the resource owner password flow.
Identity Server and my application work fine together. Identity Server give an Access Token and I can use this token to access some API that we own.
However, I was asking myself about the Access Token, users and socpes. For now my setup is this one.
I have an API that require the scope API-1.
I have a client (my SPA) where I defined the scope API-1
And I have a user.
In this configuration, it is the client who own the right to access the API, not the user. And I'm wondering how to give this scope to the user and not anymore to the client.
Stupidly, I'm wondering if user can own the scope and not the client. Maybe I've miss or misunderstood something, so please teach me.
In the Resource Owner Password Flow your client will always need to have permission to the scope that your resource is protected by. This does not mean that you cannot protect your API based on claims related to the user however.
If in your API for example you need different permissions based on the user accessing the API look to use the claims information as part of your authorization. In the Resource Owner Password Flow example at http://docs.identityserver.io/en/release/quickstarts/2_resource_owner_passwords.html you will see that it mentions this at the foot of the page, see the two paragraphs as follows:
When you send the token to the identity API endpoint, you will notice one small but important difference compared to the client credentials grant. The access token will now contain a sub claim which uniquely identifies the user. This “sub” claim can be seen by examining the content variable after the call to the API and also will be displayed on the screen by the console application.
The presence (or absence) of the sub claim let’s the API distinguish between calls on behalf of clients and calls on behalf of users.
If I have an API secured with Azure Active Directory, what is the flow when an external API wants to talk to my internal API?
Is this just an API to API call as normal or is this a special circumstance and needs handling a different way?
Is this just an API to API call as normal or is this a special circumstance and needs handling a different way?
The special circumstance may depend on the confidentiality of the resources served by these api(s) and the level of security your application needs. In the end it is an api to api call only.
There are two approaches you can use if Azure Active Directory (AAD) is your Identity Provider for the entire application.
Application Identity with OAuth 2.0 client credentials grant provided by AAD. The calling API makes a request to AAD token endpoint with its client id, client secret (credential) and the application id (the unique id for the callee API) to receive an access token as response. This token is used as Bearer token to call the downstream API. In this approach client id, client secret, application id that are exchanged for an access token, are static values. Some one who has access to these values may find a way to compromise application security (highly unlikely).
The second approach is Delegated User Identity with OAuth 2.0. A request is made to AAD token endpoint with client id, client secret, the access token received as part of calling the tier1 API and a special on_behalf_of parameter to receive an access token, refresh token as response. We preferred this approach as it uses a dynamic value (access token from tier1 api) and also provides a refresh token.
You can read more about these approaches here
If you do not want to use AAD, you can use asp.net built in OwinAuthenticationMiddleware to generate and validate your own access tokens. As said earlier it all depends on your application requirements and implementation details, but in the end it is an API to API call.
Hopefully this is helpful, please let me know if you have any questions.
Thank you,
Soma.
oAuth is done for loggin user to a webservice (see also reference here).
Use OAuth to give your users access to their data while protecting their account credentials.
As another webservice wants to consume one of your service best way to do so is to have another authentication method in order to authorize
Other API, I assume you are talking of machines and not users (alias humans).
So best way is to provide another auth mechanism in order to authorize machines to connect to your API in a safe way.
A simple way to do a machine connection is using a private PKI with public/private key.
A good reference for PKI : http://docs.oracle.com/javase/6/docs/technotes/guides/security/certpath/CertPathProgGuide.html
I'm building a native Mobile App that connects to a REST API.
I'm looking at this demo oAuth App to use as a guide for my Authentication/Authorisation layer.
When the user comes to the App for the first time I want to provide them with a username and password box.
After they hit submit I want to the App to be supplied with an access token, and a list of permissions (scopes?) that the user is permitted to perform.
I've read lots about the oAuth2 specification but am confused as to which flow to use.
I can't use the Resource Owner Password Credentials Grant because I can't trust the Native App with the Client Secret.
I don't want to use the Implicit Grant, as I don't want to present the user with a "Do you authorise this App?" web window.
I've looked into the JWT Bearer flow, and think it might be what I need as it doesn't require the Client ID/Secret. However I can't find any examples where this flow returns permissions (scopes?) that the user can perform.
Edit #1:
I am confused as to the use of Scope. The specification says-
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. If the issued access token scope
is different from the one requested by the client, the authorization
server MUST include the "scope" response parameter to inform the
client of the actual scope granted.
If the client omits the scope parameter when requesting
authorization, the authorization server MUST either process the
request using a pre-defined default value or fail the request
indicating an invalid scope. The authorization server SHOULD
document its scope requirements and default value (if defined).
From that can my Client request a list of ALL Scopes, and then the Authorization Server give a Response with the ones the User actually has?
Thanks for your help, Tom.
You list two assumptions about OAuth 2.0 flows that are not true:
the Resource Owner Password Credentials Grant can be used with a public client i.e. a native app that doesn't have a client secret
usage of the Implicit Grant does does not imply that it requires explicit consent; that is to the discretion of the Authorization Server implementation; in an enterprise setting or a setting where the same party controls the client and the Authorization Server, that may be omitted
But since the Implicit grant comes with security considerations, for native apps it is typically better to use the Authorization Code grant.
Scopes are a way for the Client to request certain permissions. The Resource Owner can grant the Client permissions that relate to these scopes (explicitly or implicitly). Since the Client will change its behaviour based on what permissions it gets, it is assumed that there's some shared understanding between Client, Resource Server and Authorization Server about what Scopes related to. There's no predefined semantics in the OAuth 2.0 specification, it is up to the implementation.