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.
Related
We are currently successfully running a Node.js Azure Function App deployed in an App Service in Azure with AAD B2C authentication as backend for a React-based Single-Page Application. User authentication in the SPA is done with Azure AAD B2C, where users obtain a JWT Token which is used as Bearer token for all requests against the backend API.
This works great.
Due to different reasons, we now need to dockerize our Function App and move it inside a Kubernetes cluster. This prevents us from using the AAD B2C integration of the Function App in the App Service for protecting the API, hence we need a different approach to validate the Bearer tokens of the requests.
From what we understand, there are two possible options to do this:
passport.js
MSAL
passport.js seems to work great for all Express-based apps and is therefore not suitable for us as our Function App is not Express-based.
We also had a look at msal-node and various examples using it, but struggle to understand exactly where and how our token validation fits and which (if any) of the examples fits our use case.
Are we looking in the right direction with msal-node and if so, how can we accomplish the task of protecting a containerized Node.js Azure Function App by validating the Bearer token with the AAD B2C?
We found a working solution. Turns out we were thinking way too complicated and "normal" JWT verification is exactly what we needed to do.
This StackOverflow post describes exactly what we were trying to achieve.
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.
The typical suggested approach when creating a client/server application (Typically for SPA apps) in Azure is to create one AAD application for the service (API) and another AAD application for the client application (E.g. Angular Spa). While I understand the mindset behind this, are there any implications creating one AAD application for both and share the same configurations values (ClientId...) between both applications? This simplifies the implementation, especially when there is only one type of client app (E.g. Web) that consumes the API tier.
I think you might want to take a look at the documentation as it might explain what the app registrations are meant for : https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-overview
This specific tutorial goes over the SPA Scenario : https://learn.microsoft.com/en-us/azure/active-directory/develop/scenario-spa-overview
The purpose behind creating an AAD App Registration for the Server is so that the client is able to request an access token for a the web API resource. For example, if you're trying to access the Microsoft Graph API, you would request xyz permissions to make a call to the Microsoft Graph's xyz API.
And the V2 Overview and the SPA Scenario Overview both go over this very thoroughly.
Note that you are not creating an AAD App Registration for your client, your creating one for your server and custom web API resource. So you would have a client requesting an access token with the server's information to get access to the web api.
In addition to that, you'll want to be clear on which endpoint you're using. This goes into that a bit further as well : How do I check to see if my AzureAD version is V1 or V2?
And here are some reasons why one would want to use the v2 endpoint : https://learn.microsoft.com/en-us/azure/active-directory/develop/azure-ad-endpoint-comparison
Here's my current situation:
Xamarin iOS mobile app (using MobileServiceClient to login)
Azure Mobile/App Service (ASP.NET Web API) with Azure AD authentication
I would like to modify the Authentication part of this process to be handled by Okta instead of the Azure AD. How can I setup Okta or any other 3rd party Identity Provider Service similar to Okta as the ipd for both my mobile app and the api web service? Azure claims that you can use any Auth capable 3rd party provider but I don't see any way to integrate such a provider in Azure portal.
I found this url to a tutorial for custom Authentication: https://adrianhall.github.io/develop-mobile-apps-with-csharp-and-azure/chapter2/custom/
From this post:
IdentityServer 4 as Identity Provider for Azure App Service
Is this really the only way to do it? I would really rather keep using the server flow through MobileServiceClient and configure Azure to use the 3rd party OAuth identity provider, does any one have an example or additional information on how to do this?
Thank you for your help, maybe someone from the Azure team can enlighten us on this topic, I have not seen any documentation or examples of how to do it in their documentation so far.
Client:
Found a working library for OAuth2 and OpenID that worked for integrating with Okta:
https://github.com/openid/AppAuth-iOS
https://github.com/openid/AppAuth-iOS/tree/master/Examples
with a Xamarin wrapper:
https://github.com/xamarin/XamarinComponents/tree/master/XPlat/OpenId
Tested it with Okta for client Auth with 2 factor authentication and it works well. On to figure out the App Service part.
After more research and trial and error, I've found the right combination that works for what I'm trying to do. Here's an outline of what it is:
Okta (identity provider)
set up a native application with an Implicit (Hybrid) grant on it
Mobile Client
use an OpenID Connect component for Xamarin.iOS, in my case https://github.com/openid/AppAuth-iOS
Server / Web Api
converted my asp.net web api webservice to an asp.net core web api webservice so I can use the latest owin middleware to validate jwt bearer tokens submitted in the header of calls to the secured endpoints, here's an example of how to set that up with Okta: https://developer.okta.com/quickstart/#/ios/dotnet/aspnetcore
One thing to note that tripped me up along the way:
in the client, after successfully authenticating with Okta through an OpenID Connect component, you will receive user information which will include an id_token and an access_token, although it might seem natural to use the access token to send with your api calls to the server, that's actually not the case, the access token is supposed to only be used to get userinfo and is not a validated token because it gets regenerated regularly, id token on the other hand contains the signature that the server needs to validate that the header and the payload of the token haven't been tampered with, this difference between these two tokens can be observed by the number of . delimited parts contained within the token, access token has only 2 . delimited parts, header and payload, id token has 3 such parts, header, payload and signature
read more information about jwt tokens here: https://auth0.com/learn/json-web-tokens/
After a lot of searching, most of the scenarios moves all the authentication to Azure AD and WebAPI just has to know how to read the token. (To achieve this we are using Azure AD middleware in OWIN pipeline). Also, this means that any client that wants resources from the WebAPI has to authenticate to Azure AD on their own (For example: adal.js for JS). Lets say my I want to keep user info within my WebAPI. I suppose I can easily just Create/Read users using some unique field in Azure AD JWT token and I do not need to worry about token validity or any other stuff about security since this middleware does that for me. Simply, I can just use it.
And here comes the mystery that I can not understand.
What if my WebAPI requires specific claims that Azure AD does not provide. For example authorization (permissions and so on) or even organizationId (in multitenant application).
Azure AD works as external identity provider, same as Google, Facebook and so on. But the difference is that most of user authentication logic lives in WebAPI (at least with the examples you can find). Client application receives a list of external providers a WebAPI supports and that is it. This gives an opportunity to introduce LOCAL AUTHORITY tokens with the claims WebAPI would need. But it kind of means that you start creating your own identity service within WebAPI, you also have to manage refresh tokens and so on.
Does it mean that the proper solution would be to start using IdentityServer that integrates variety of external providers and manages token creation with specific claims that my WebAPI would expect?