I am finding it hard to understand how I can differentiate multiple client applications using oAuth 2.0.
Using APIM I mapped my backend webservice to Azure API Gateway Service URL. I have configured Oauth 2.0 with grant type as client credentials because its a service to service integration.
In Oauth registration, I have mapped my client and backend app Id's with secret keys - (OauthSample1.0).
It doesnot have the provision to configure multiple clients for the same backend service.
And, in my API, i can add only one Oauth reference - (OauthSample1.0). Even if i would go ahead and create multiple Oauth 2.0 references for different clients, technically it cannot work with the API configuration.
This means I can have my API validate only one specified client using one oAuth 2.0 reference.
If I want my API to be accessed by different partners / Client applications, my understanding is that I would need to create different Clients in Azure AD. But unfortunately not able to design the solution here.
The official doc for protecting your API using OAuth 2.0 covers the steps required in detail.
To summarize, the steps are
Register an application to represent the API
This app is setup to expose an API
Register separate applications to represent each of your client applications
These apps would also have a secret generated for the client credential flow
These apps would have been granted access to the exposed API
Setup a Validate JWT policy to pre-authorize requests.
Your clients would have to get the token using the client credentials flow before making the requests.
Also, if your clients are services that directly access the APIs, then you could setup app roles that show up as Application Permissions instead of Delegated Persmissions.
Related
We are using Azure AD for authentication and authorization. Our angular spa has been enabled SSO with Azure AD. We need to secure our backend
service and only allow API which has a valid jwt token.
What we have done so far is:
Registered our angular app in Azure AD.
We have configured spring microservice as a resource server and
application properties contain jwt.issuer-uri
spring.security.oauth2.resourceserver.jwt.issuer-uri=XXXXXXXXXXX-XXXXXXXXX-XXXXXXX-XXXXXXXXXXX
The issue is the token that we get from Azure AD is having an audience as "00000003-0000-0000-c000-000000000000" which means the token is generated for the Microsoft graph. I also tried accessing graph Api with this token and it worked. But what we want is to verify this token in our own spring microservice and grant permission
based on jwt provided.
To solve this issue I had to make some config changes in our Azure registered Angular app. I have added a custom scope api://<>/app and use
this scope while acquiring the token. Now the token is being validated in the backend and API working fine.
This config somehow works but doesn't seem correct to me. I am new to azure so am not sure how all things tie-up.
The new token which is now being generated has an audience as our
angular spa client Id. Is this correct? Shouldn't it be the backend
service? Any why it's getting validated by the backend with the
current configuration?
My understanding is that we don't have to register our spring
microservice with Azure Ad. I will just act as a resource server and
will decode the token provided by the angular app using the
issuer-url.
In case we need to register our backend services with azure AD then
would it be difficult to do the same for all microservices?
I have done all settings by referencing.
https://ordina-jworks.github.io/security/2020/08/18/Securing-Applications-Azure-AD.html
In some other links, I find a completely different config for setting up backend service. I am not sure which one is correct.
https://learn.microsoft.com/en-us/java/api/overview/azure/active-directory-spring-boot-starter-readme?view=azure-java-stable
Azure AD is a little confusing when following a standards based approach. I wrote a blog post on this a couple of years back:
You have already figured out that you need at least one API registration to work, to expose an API scope - so that you get usable access tokens
The generated id from the API entry in Azure then becomes your audience, as in step 9 of the article.
What we'd really like to do is this, so that we can do things like forward the JWT in microservice to microservice calls:
Get Azure AD to issue an audience claim such as api.mycompany.com that is common to all microservices
Issue multiple scopes in the access tokens, based on areas of data in microservices - as in this Curity doc
I would aim for a single entry in Azure AD to represent your platform of APIs. Then each microservice can use the same generated audience value.
Hopefully you can get multiple custom scopes to work also, though there are some annoyances here, especially when you want to use built in OpenID Connect User Info scopes, which Azure AD exposes via the Graph API.
I realize that AZURE APIMS has a lot out of the box. Including subscription based server-side authentication.
However, I would like to know:
What options are available for client apps which are browsers?
For example,
Assume I have a single backend API with a single endpoint. I want to expose this endpoint to external business partners who use browser based applications which make requests to the backend from client side (browser)
How can I achieve this using AZURE API management service?
APIM supports protecting your API with OAuth 2.0 which you can setup on your APIM instance and leverage in your browser-based applications.
Your application would first have to get the JWT token from your identity provider and then provide the same in requests to the APIM endpoint which are pre-validated using a policy.
Here are samples of applications using AzureAD (and its MSAL library) for authentication/authorization.
I have a cordova application which I am authenticating using azure AD cordova plugin and it all works fine. But now I am integrating services published in another domain and I am unable to authenticate these services using the mobiletoken generated after authentication. Can someone guide me how to secure multiple domain APIs published as Azure web APIs and use token to access the secured APIs.
I have tried to modify the secured settings in azure portal of one of the APIs by including reply URLs for both the APIs
When I include the token in the header of the ajax requests going into 2nd domain endpoints, I just get "unauthorized" error.
It sounds like you're able to get an access token in a Cordova setting and you're having issues accessing multiple web apis after the user has logged in.
The authentication protocol I would suggest you utilize is the on-behalf of flow which is doocumented here : https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-on-behalf-of-flow
Per the summary :
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.
This is to get a new access token with the right audience to gain access to web api 2.
I'm working with a client to define a security strategy and have got stuck trying to get something working. I'm new to Azure AD so this may actually not be possible.
Consider the following application landscape.
I have 4 "API" applications:
API-A, requires interactive user and role based permissions
API-B, access via service demon, client_credential grant
API-C, must not be authenticated against directly
API-D, access via service demon, client_credential grant
A user / demon authenticated against API-A or API-B should be able to access API-C as well. However the demon authenticated against API-D must not be able to access API-C.
I was expecting to be able to use the "Expose an API" and "API Permissions" of the App Registrations to be able to control to "roles" returned in the JWT, I cannot seem to get it to work or find any decent guide on how this can be achieved.
EDIT: For clarity the API applications are not hosted within Azure, I am just looking to use Azure AD to provide authentication
It may be helpful for you to distinguish between client apps and API apps (or resource servers in OAuth2 lingo). Each of them has to be registered separately. Your list above seems to merge them together, which is a likely source of confusion for you.
The former (client apps) acquire tokens, the latter receive them from the clients with the service request. Authentication is only only involved when client apps acquire tokens. APIs do not authenticate - they use tokens to authorize access to their services. Clients acquire tokens either on behalf of a user - and the user authenticates and consents as part of the process, or on their own behalf (client creds). In AAD an API app may expose/define scopes/permissions which may be included in one or both of these token types. An API may decide not to require any tokens (sounds like your API-C). You Expose (available) Permissions on API apps, you specify (required) API Permissions on client apps. At runtime (if using the AAD V2 endpoint) a client may request fewer scopes than it is is configured with as Required. That applies only if the client is using delegated tokens (user based). (Note that an API app may also be a client app to another API app (common in multi-tier systems).
BTW, where the clients or APIs are deployed is totally immaterial to the above. At most deployment affects the value of the reply url you need to specify for some client apps (not APIs).
I have an API hosted in Azure (Web App). This API can't be accessed directory by every client (IP Restriction), and I am willing to use APIM to protect it.
Users will call the APIM-Gateway and the gateway should responds appropriately.
One big problem is authentication: I am protecting this API (The Backend API and not the APIM-Gateway endpoint) with AAD.
So users should authenticate themselves against AAD and access the resources with no direct access to the backend.
Is it possible to implement such a scenario?
If you're fine with users authenticating against AAD then it's perfectly supported. With that model APIM may be used to just pass-through user requests to backend or you could use validate-jwt policy somewhere in request processing pipeline to validate users' tokens and authorize invoked actions.
APIM's authorization servers feature may be used to document that your APIs require AAD token from certain server. If this is done test console on developer portal will show controls to simplify getting token to make test calls to your APIs.
Normally APIM requires clients to pass subscription keys to authenticate and authorize calls. But if you're relying on AAD that may be not something you want - then you can use Open product to make your calls anonymous to APIM. validate-jwt policy can still be used to require certain token to be present with request.
There are various ways you can ensure that your backend is reachable only via APIM:
Shared secret - set a special header in APIM policy and check it's value on backend.
Client certificate authentication - APIM may be set up to attach client certificate to each request to backend that you will check at backend side to make sure that this is APIM making a call.
VNET - APIM can join your VNET, while backend may be setup to accept calls only within VNET making it possible to be called only through APIM.
I have used below approach in my recent project and used jwt validation to validate oauth2 token in policy
Follow Microsoft document link https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-protect-backend-with-aad.
Here is a quick overview of the steps:
Register an application (backend-app) in Azure AD to represent the API.
Register another application (client-app) in Azure AD to represent a client application that needs to call the API.
In Azure AD, grant permissions to allow the client-app to call the backend-app.
Configure the Developer Console to call the API using OAuth 2.0 user authorization. (optional)
Add the validate-jwt policy to validate the OAuth token for every incoming request.