I am trying to call an API (API2) from another API (API1) with the help of client credentials flow. Is it possible to grant access to only some parts of API2?
To give some context, When making call from API1 to API2, I am currently using a service account that decides what parts of API2 are allowed access. The service account is created and configured (with roles) in API2 and shared with API1 ahead.
I am trying to achieve this same with oAuth's client credential flow but I could not find any information on restricted access inside API. I believe ApiScopes won't work in this case.
Could you let me know if restricted API access is possible in client credentials flow? or can this be achieved in any other flow?
Regards,
Siva
Yes, you can use the built in authorization system in ASP.NET Core to control access based on the claims inside the received access token. what AddJwtBearer do is to convert your access token (once authenticated) into a ClaimsPrincipalUser object.
See these links for details:
Policy-based authorization in ASP.NET Core
Claims-based authorization in ASP.NET Core
Alternatively, we can define a new Application Role for the API2. This role will have access to selected parts of the API2. Then we can add this role to the Client_id you are using in Client Credentials flow.
Related
Our OAuth client application is built with Spring (through JHipster). The OAuth provider only serves the authentication functionality, but not the authorization functionality. Ideally, we should only allow a small group of people to access our OAuth client application, but not all those users who can sign in to the OAuth provider.
A solution I can think of at this moment is to create a custom user role to control the access in the OAuth client application. That, however, only can be done after the user's first sign-in when the user account data is created in the application.
Any better solutions?
Ideally you would apply user access control before creating user account data is created in the application. You could do so by providing an application specific scope or claim in the token that is generated for your application (aka. Client). Upon receiving the token, the application would check for the required attribute in the token before allowing access.
I have a Rest API that is used by different clients:
Browser, when using swagger
Postman, when calling API
Curl
Other HttpClients, jvm, Python and such.
I want all clients to get authenticated with Azure AD. So each of them has to have an email, authenticate itself in front of Azure AD and then pass some token to my Rest API, on the backend I will validate the token. I really don't understand which flow to use. The one that is closest to my scenario seems to be Credentials Flow but I still don't understand how it fits in.
This picture is what I am trying to achieve:
The OAuth 2.0 On-Behalf-Of flow (OBO) serves the use case where an application invokes a service/web API, which in turn needs to call another service/web API. The idea is to propagate the delegated user identity and permissions through the request chain. For the middle-tier service to make authenticated requests to the downstream service, it needs to secure an access token from the Microsoft identity platform, on behalf of the user.
Based on your scenario it is recommended to use On-Behalf-Of flow (OBO).
Can I define custom scope(s) and have them returned when using the client credential flow in Azure AD?
In my experiment, I configured 2 Azure AD applications, one for a Web API and one for a client (Web API Client A). I added a scope to the Web API but when requesting the access token via the client credential flow, the scope wasn’t returned. 🤔
Also, it only allowed me to request an access token when using .default for a scope, i.e. api://web-api-client-credential-flow/.default.
I ran across this Azure Feedback item: V2.0 Client Credentials Implement Scopes so it appears scopes aren't supported in Azure AD under the client credential flow?
What’s the point in giving my Web API Client A application permissions for that scope if they are not returned? How could the Web API know if the daemon application has that scope to perform the necessary action?
It would seem I would have to use application permissions?
Yes, you have to use application permissions.
Scopes aka delegated permissions only apply when a user is involved in the login process.
They allow you to act on behalf of a user.
Application permissions are sort of roles given to the application itself.
They only apply when doing client credentials authentication, where no user is involved.
You can define application permissions on the app via the Manifest in the app registration.
These can then be assigned to the client application.
When getting the token, you must use .default because you cannot change your app permissions dynamically.
You always get what has been granted already.
In the token the permissions will be in a roles claim.
Can I define custom scope(s) and have them returned when using the client credential flow in Azure AD?
No, but you can define application permission(s) via the manifest (definitely not as nice as the UI for delegated scopes) and have them returned via the client credential flow:
Then you can provide the client app permission:
Now when requesting a token with a scope of api://web-api-client-credential-flow/.default the "scopes" are returned in the roles claim. Sample JWT
Yes, you need to use api://web-api-client-credential-flow/.default for client credential flow.
And the application permissions will be returned in roles instead of scopes.
Currently, we are building a web-based application, and we have web-server and we have application server host our resources. Also we will use Mule ESB to be able to use any web-service or api. And we will have Alfresco DMS solution and we will use alfresco service with Mule ESB .
We are investigating how we can implement SSO approach for this scenario. We have already IdentityServer4 for identity federation. It issues access token for client, and we need to authenticate the user whenever the user at the Mule ESB side without asking user the credentials again.
According to my researches, external Identiy provide can be added on Mule ESB. The thing we do not is that can the access token issued the cliet while user logging into application server be passed to Mule ESB and Mule ESB can validate the access token before
Actually, the question that we are looking for answer is that is it possible issue client an access token only for once, then validate this token in each side (Mule ESB, Alfresco) without asking user to enter the credentials again and again.
Using access token for multiple applications is not recommended. This is highlighted through this and this resources. Basically scope of the access token must be restricted. This is to precent access token being misused.
In your scenario, you have multiple applications. If you goal is to use one access token shared across all of them, I suggest not to do that. Instead, you may use single access token against multiple APIs given that you request access tokens with such scope. For example, APIs in ESB can be designed to accept access tokes if scope allowed to do so (scope can be validated from API endpoint through token introspection). But allow each client app to obtain their own tokens. This make your architecture more secure.
One solution for SSO is to allow browser based SSO. Identity providers maintain a session in the browser. So if one of your client go through a login, your next client will use that previous session to skip the login page. This is essentially a SSO behavior. For example this is what allows you to use Gmail, Youtube and Google Drive with single login. Browser maintain a session with Google. Each app obtain tokens, but skipping login page.
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