Trying to add Auth to an Ocelot API Gateway I ran into some issue. Project is running .netcore 3.1 using Microsoft.Identity.Web as this should be the new common ground for MS auth.
Azure B2C is setup and I'm able to retrieve auth code and bearer tokens based on the auth code.
Then tried the tokens with the API, but Ocelot rejects all the time.
I found some different config for AzureAD and AzureAdB2C combined with Ocelot, but not sure the are up2date.
As far as I can see this call should be enough to configure
services.AddMicrosoftIdentityWebApiAuthentication(Configuration);
The docs on combining Ocelot and Azure B2C does not seems to be updated very recently. All help is appreciated, thanks.
Related
We developed an API hosted in Azure and we decided to experiment a frontend in Azure DevOps with a web extension in react.
Without authentication, it worked :D
So, let's move on OAuth2.
In the past we developed task extensions with custom service connections. So we decide to experiment them with the acceptance criteria of an authentication based on AzureAD (or related to as Azure DevOps) with userId in claims in API scope and keep benefit of Azure DevOps not to ask a second authentication to users. (no MSAL for now....)
Simple first solution was to use core sdk getAppToken function. But token was not containing userId information.
We them tried service connections :
Client credentials
Native azurerm service connection works but with some limitation. We can't use a datasourcebinding with datasourceurl as it should begin with {{config.url}} or {{endpoint.url}}. And endpoint.url is "https://management.azure.com", so we can't call our api :
We also tried to use managed service identity service connection type (ms.vss-endpoint.endpoint-auth-scheme-managed-service-identity for curious). Because in task extension frontend, Azure DevOps is using user credentials to request Azure for any datasourcebinding.
But Microsoft seems to block this kind of authentication to their type azurerm :
Let's now try OAuth2 configuration :
So we created a custom service connection and defined authentication and datasource like ServiceNow endpoint :
https://github.com/Microsoft/azure-pipelines-extensions/blob/master/Extensions/ServiceNow/Src/vss-extension.json
OAuth2 configuration url : https://login.microsoftonline.com/XXX/oauth2/v2.0
AuthorizationUrl : {{{configuration.Url}}}/authorize?client_id={{{configuration.ClientId}}}&response_type=code&redirect_uri={{{RedirectUrl}}}&scope=api://XXX/.default
AccessToken and RefreshToken datasourcebindings requestUrl {{{configuration.Url}}}/token"
Everything was in place to use a configuration.url for code and token. Whereas endpoint.url was pointing to our API in Azure with a custom domain.
But it failed because I realized when a code is requested through service connection of kind OAuth2, serverurl is magically replaced by configurationUrl...
I didn't understand this issue with executeServiceEndpointRequest function call :
Backend code is inspired from mkaszub post : https://github.com/microsoft/azure-devops-extension-api/issues/12
It comes before real request and after service connection get.
The strangiest thing is that next call to API itself failed but not because or bad url. First endpoint.url at service connection creating was still there...
Conclusion, fail to use OAuth2 configuration in Azure DevOps with an Azure API.
So, do you know how to call an API inside Azure DevOps web extension with a user generated AzureAD token ?
Solution we think of :
MSAL should be the way to go for standard authentication, but we will need to ask for user to login. Even he's already inside Azure DevOps. Any trick to avoid this ?
MSAL with frontend outside Azure DevOps, inside Azure. But we loose Azure DevOps integration. And using extension with hub collection, would brings unique API frontend places.
Anyway, Thank you for time you spent reading me.
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'm building an REST API which should be protected by Azure AD. So I have the following OAuth2 items
Resource Server: My REST API server
Authorization Server: Azure Active Directory
Client: Postman
Resource Owner: me
I've been trying to configure AD using this blog post but then it goes straight to configure a frontend application. In the blog post, the author configured a front end application but during development, the front end is not yet ready, so I will be using Postman
And when I tried using Postman using the Get New Access Token functionality (Grant type is Authorization code with PKCE), it is failing with error Error: AADSTS9002327: Tokens issued for the 'Single-Page Application' client-type may only be redeemed via cross-origin requests
Any thoughts on how I can properly test this? What am I doing wrong?
Please refer to this cogent article on testing Azure AD protected Springboot API: Securing a RESTful API using Spring Boot and Microsoft’s Azure Active Directory.
Here are some screenshots for quick reference on setting up Postman:
Similar question to this; I've started working on an Azure Functions app that'll trigger AzDO build pipelines, but am having trouble authenticating via Oauth. I'm either getting a 203 Non-Authoritative Information status code, or a 400 bad request so far. I've gotten it to work with a personal access token, but would rather have users log in via Azure AD and authenticate that way.
I've tried using the instructions from Authorize access to REST APIs with OAuth 2.0, registering the app and sending requests to the auth and token URLs to no avail.
Is the best option to perform something similar to Service to service calls on behalf of the user, or is there another option I'm missing? Any help and/or examples would be greatly appreciated!
I wrote a little server in node.js and deployed it to Azure WebApp. I want to add service-to-service authentication using Azure AD OAuth (like this flow). I alredy did this in another WebApi sevice using Katana.
So, I found the official library for this, and it work great. The only problem is that the library use the ursa module, which is a native module. And, like explained here it is not easy to deploy a WebApp with native modules.
So, my question is - what is the best approach? How I could accomplish authentication using Azure AD OAuth?
Thanks,
Omer
Take a look at the Authentication / Authorization feature of Azure Web Apps. It allows you to do OAuth 2.0 service-to-service auth flows using Azure AD, no code changes necessary (also, it works with any stack, not just node.js).
More high-level info here: http://azure.microsoft.com/blog/2014/11/13/azure-websites-authentication-authorization/
The post is a bit dated and doesn't mention the recently added support for APIs, but if your client can acquire an OAuth token from Azure AD, you can send it to your node.js server as a bearer token in the Authorization header of your HTTP request and have the authorization just work.
Two things to be aware of if you go down this route:
Authentication / Authorization currently blocks ALL unauthenticated access to your node.js API. You won't be able to say that some APIs are protected and some are not.
The JWT token that you send to your node.js API must use the client_id GUID value as the value for the "aud" claim. Using the app URI (as shown in some Azure AD samples) will not work.
Give it a try and see if it works for you.