I am trying to access an API on the same server that my android app is registered. The process of logging into the android app works fine. I have attempted to use the IAuthenticationResult.getAccessToken() generated to access an API on the same server unsuccessfully. I get a 401 Unauthorized error message both on Postman and my application. The sample applications available work fine with Microsoft Graph but I haven't seen any sample accessing other forms of API including those hosted in the same client.
The solution that worked for me is specifying the SCOPE parameter in the android code as {"https://graph.microsoft.com/.default"};. That was the only way I could obtain a valid bearer token that could be validated on the backend by calling https://jwt.ms/
Related
Here is the problem.
I have an .net core web-api application with azure-ad authentication.
When I've added necessary AzureAD section to my appsettings.json file and redirect url-s to appregistration my backend worked fine.
But later I added build of react project to wwwroot folder and now, when I try to call backend method with authorize attribute I get CORS error from Loginmicrosoftonline
[CORS error from Loginmicrosoftonline]
First of all, web api project should be a daemon application so it doesn't have a sign in page as normal, nor a redirect url for AAD. And we can integrate AAD to protect our api but the api shouldn't ask users to sign in first.
In your scenario, it looks like you want to let users sign in in your react frontend app, then generating access token to calling the protected web api. I think you need to refer to this sample to integrate MSAL library in your react app(this sample containing an api written in nodejs, you can ignore api part since you had asp.net core api), and this sample for protecting your web api. You may also take a look at this answer.
And go back to your CORS issue, it appeared because you didn't use MSAL.js in your react app but directly going to the login URL. Microsoft identity platform required developers to use the library. I used to using ajax request to send a get request to the login url, and I got Cors issue as well.
I am researching the feasibility of porting an existing Vue 2 app to be an Azure Static Web App (SWA). A requirement is the ability to run the Vue app locally and authenticate against our Auth0 tenant to retrieve a access/bearer token to send along with our HTTP requests.
It appears that a SWA can utilize custom authentication (Auth0), and I was able to complete that successfully by following this article. However, I'm not seeing any information around capturing the access token. There is an /.auth/me/ endpoint which has user information, but that does not contain the access token:
I also looked into the Azure Static Web App Emulator which allows for defining an identity profile when running locally, but I'm not seeing a way to specify an access token here either.
Is it possible at the moment with a SWA to obtain an access token using a custom auth provider when running locally and when published live?
Managed Authentication in Azure is really only useful for fairly simple use cases. I think you're going to want to implement your security directly inside your Vue application.
https://auth0.com/docs/quickstart/spa/vuejs/01-login
You mentioned needing an access token but didn't say where it comes from or what you're doing with it. Are you trying to call an Auth0-secured API?
https://auth0.com/docs/quickstart/spa/vuejs/02-calling-an-api
The app
I have a web application on Microsoft Azure. The client is written in Vue.js and hosted via a Windows App Service. The server is built using Azure Functions, and hosted via a Linux Azure Functions App.
Both the client App Service and the server Function App use built-in authentication ("Easy Auth"), with Active Directory configured as the identity provider. I am able to log into each, separately, via AD.
Until recently, I was also able to make authenticated requests from the client to the server. The client has
"loginParameters": [
"response_type=code id_token",
"scope=openid offline_access api://<Application (client) ID>/user_impersonation"
]
in its authsettingsV2 and generated tokens' aud have the correct application ID. Passing the access_token from the client's /.auth/me response as a bearer token in requests to the server used to work.
The problem
I made a few configuration changes today, tested authentication, found that it was no longer working, and backed them out. Unfortunately, reverting those changes didn't fix the issue and generated tokens are no longer being accepted by Easy Auth on the server:
{
"code": 401,
"message": "IDX10205: Issuer validation failed. Issuer: '[PII is hidden. For more details, see https:\/\/aka.ms\/IdentityModel\/PII.]'. Did not match: validationParameters.ValidIssuer: '[PII is hidden. For more details, see https:\/\/aka.ms\/IdentityModel\/PII.]' or validationParameters.ValidIssuers: '[PII is hidden. For more details, see https:\/\/aka.ms\/IdentityModel\/PII.]'."
}
Okay, so the issuer is not in the list of valid issuers. But Azure hides personally identifiable information in exceptions by default so I can't see the issuer or any of the valid issuers.
One option appears to be:
If you need to see the full information present in exceptions, please set IdentityModelEventSource.ShowPII to true
but this looks like a reference for configuring authentication myself using C#. I don't see any way to change this setting when using Easy Auth.
Maybe I can access raw logs. Let's see, I should be able to see this information by enabling application logging:
If you enable application logging, you will see authentication and authorization traces directly in your log files
To enable application logging for Linux apps or custom containers in the Azure portal, navigate to your app and select App Service logs.
But that option is not available:
A lot of the Function App documentation links to App Service documentation, so it would seem that Function Apps are a special kind of App Service App, but maybe not. The preceding quote is from App Service documentation, but I got there following links from Azure Function App documentation.
Alright, let's see if there's a way to enable application logging for Function Apps. Azure Monitor Logs look promising, but none of the generated logs appear to be about Easy Auth. I just see messages about the service starting. Maybe that's because, on Linux apps, Easy Auth runs in an isolated environment and therefore wouldn't be included in diagnostic logs:
The authentication and authorization module runs in a separate container, isolated from your application code.
So… how can I get more details about this error? Easy Auth is recommended as an option for authentication with Function Apps, and I'd hope that there's a way to get more information about what's happening.
I have seen Azure App Service Authentication / Authorization returns HTTP 401 IDX10205: Issuer validation failed and have already set accessTokenAcceptedVersion to null in the manifest. That Q&A helped me get the token passing working in the first place, and I have not changed that value.
I'd like to use Visual Studio 2017 to build Azure Function App with HttpTrigger. However, I can't find the way how I could add Azure Active Directory authentication to secure the end point.
Will it work if I just add jwt token to the http request and then call ClaimsPrincipal.Current.Claims inside the method? Is there any other solution?
AFAIK, the authentication for the external identity data provider only can config on the Azure portal. And if you host the Azure function on Azure, the answer is yes. However if you host the Azure function on local, there is no way we can config for the authentication using Azure Active Directory.
As a workaround, you need to get the token from headers and verify the token manually before run the function code. And if you want to support to config the authentication for host Azure function on local, you can submit the feedback from here.
You can use the Microsoft OpenID Connect and JWT libraries to validate the token and get claims based on a received access token. Here's an example: https://github.com/azure-samples/ms-identity-dotnet-webapi-azurefunctions/tree/master/
Create an app registration in AD
Issue a browser request to get an access code
Issue an HTTP POST request for an access token using the code and the secret via cURL
Send the access token as an Authorization Bearer header to the local function endpoint
I had issues using newer versions of Microsoft.IdentityModel.Protocols.OpenIdConnect with .NET 6.0 and Azure Functions 4 and had to fall back to version 6.10.2.
My question is [Similar to this one1, but with third party providers instead of active directory.
I have an end-user UWP app, and I want to consume my Azure API App. I am NOT Azure mobile app and it's client side SDK.
Most of documentation is of sort "copy paste this magic code" and never explains how authentication actually happens.
I was inspecting mobile app SDK because Microsoft's documentation says that it's auth. process is the same.
From what I see, the mobile App SDK opens a web-view very similar to that produced by a WebAuthenticationBroker. Then every request to the server is accompanied by a header X-ZUMO-AUTH and a token. It appears that this token is issued by the azure app service, not the original provider. It is much longer than the tokens issued by Twitter or Google.
At the same time when I point web-browser at the end-point and go through the log-in process, I see that the browser is using a Cookie: ARRAffinity=c4b66198677464de573103f7aa267c33ea38617020514011cea4506e0a55d9d0; AppServiceAuthSession=EIVymV
Questions:
The problem is Mobile app documentation is it just provides
instructions on how to use the SDK. I am unclear on how I would
obtain the token issued by the app service.
Everyone knows how to obtain access tokens for Google
and Twitter. Can they be used to access Azure API apps?
You are correct that API apps use the same built-in authentication as mobile apps. The basic flow looks like this:
Login to the app using provider credentials. This can be done using either a client-directed flow using your provider's SDK or can be done using a server-directed flow involving browser popups (i.e. the web view you mentioned). In the latter case, there is an endpoint at /.auth/login/ which is provided by App Service and manages the login flow for your app.
App Service will respond to your client app with a session token (a JWT).
You call into your APIs using the session token from #2. It is passed via the x-zumo-auth HTTP request header (it's named this way for legacy reasons).
The AppServiceAuthSession cookie you are seeing is the session cookie for when you use a browser to do authentication. ARRAffinity is an internal routing cookie used by App Service and is not related to auth.
If you're looking for more internal technical details on how the built-in App Service Authentication / Authorization works, check out my blog, starting with this post: http://cgillum.tech/2016/02/01/architecture-of-azure-app-service-authentication-authorization/