I'm creating a Web Test in Visual Studio 2017 for Performance Testing. Our web application is an Azure with an AAD authentication frontend. It is the authenticating as a test user that is failing. While recording with VS or fiddler, I'm failing to playback the test again. I believe it is a token issue.
I'm able to see the Authentication Bearer Token in Location parameter of Response Header in the Browser. Example-
Request URL: https://login.microsoftonline.com/login.srf
Response Header:
Location: https://domain.fake.URL/login#id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IkhCeGw5bUFlNmd4YXZDa2NvT1UyVEhzRE5hMCJ9.eyJhdWQiOiIxZDYwOGIxOC04YjI2LTQ0MDktODg3ZC1mZmIzY2MxYzEwNDQiLC.....
However, I'm unable to get the Bearer Token in Visual Studio. I checked Visual Studio is making the same request with same parameter but in the response it's getting the below error not the token.
Location : https://domain.fake.URL/login#error=invalid_grant&error_description=AADSTS50008%3a+SAML+token+is+invalid.%0d%0aTrace+ID%3a+3c5c2728-f013-49e3-a91d-88a683210800%0d%0aCorrelation+ID%3a+f21fda63-6dc7-4b35-9b46-fc354cc4e8ea%0d%0aTimestamp%3a+2019-05-16+06%3a23%3a48Z&state=29ee5c1a-f49a-4358-be60-8f722f1e6e80
Instead of the token.
Is anyone faced similar issue? Thanks, guys.
When you recorded the test, it is likely you went through a federated sign-in process with your organization's on-premises AD FS. (This federated sign-in may have been transparent, as a series of redirects.) As part of this federated sign-in, your organization's AD FS will have issued a SAML token identifying the user to Azure AD. Azure AD will have then verified that SAML token, and since everything checked out, it issued it's own token to the application (the response with #id_token=...).
However, when you attempt to replay those steps later, the original SAML token issued by AD FS (during the original recording) has expired and is no longer valid. So instead of Azure AD redirecting back to your app with the expected ID Token, it redirects back to you app with the error about a bad SAML token.
You should be able to verify this by recording a fresh sequence of the sign-in, and replaying for the test immediately. You'll likely find that the test will pass at first, and then will eventually start failing again once the token expires.
The solution to this depends a lot on your test environment, your Azure AD and AD FS environment, and what specifically you're trying to load test. One option is to use a cloud-only dedicated test user, from a dedicated test tenant in Azure AD (you should not include any credentials for real users from your production environment in your tests). If part of what you're trying to validate includes the federated sign-in, then you should use a test instance of AD FS, and federate your test Azure AD tenant with this test AD FS.
Related
We are integrating the Role Assignments - List API from Microsoft Azure Cloud Management APIs, Link to documentation: https://learn.microsoft.com/en-us/rest/api/authorization/roleassignments/list#errordetail
We have done all of the configs mentioned:
Registered a multi-tenant web app with Azure Active Directory for OAuth using App Registrations option,
Also enabled the https://management.azure.com/user_impersonation scope under Azure Service Management
Same scope is requested by the web app
So far OAuth succeeds but the access token received when used to call an API GET https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleAssignments?api-version=2015-07-01 it fails with 401 Unauthorized error. I have replaced the subscriptionId with the appropriate value while making actual call.
I looked at the details of access token using https://jwt.io/ and the scp element only seems to have "scp": "User.Read" scope, Missing the user_impersonation. Though the AUTH dialog from Microsoft login service shows clearly the requested user_impersonation grant. The user account I am using for the OAuth has access to the given azure subscription.
What might be the problem?
It's important to add scope with https://management.azure.com/user_impersonation when requesting for an access token.
Test using implicit grant flow in browser:
https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/authorize?
client_id=<your-app-id>
&response_type=token
&redirect_uri=<your-redirect_uri>
&scope=https://management.azure.com/user_impersonation
&response_mode=fragment
&state=12345
&nonce=678910
Note: If you use client credentials flow, change scope to https://management.azure.com/.default.
I'm having some problems with the Alexa account linking authorization.
These are the steps I followed:
I got the credentials (client id, client secret...) from the Google Cloud Console
Setup on the Alexa Developer Console, using 'Auth Code Grant' as authorization grant type
Activated the skill on my Alexa application and successfully logged in with my Google account
Now I got the access token in the request, in handler_input.request_envelope.context.system.user.access_token
The problem is that the access token expires after one hour and Alexa does not manage the refreshment of the token.
What should I do to avoid having to ask my users to login every time after one hour? Should I use Implicit grant as authorization type? Should I get a refresh token somehow?
Additional info: it's a custom skill that connects to an AWS Lambda using Python3
While #pinoyyid's answer was correct, it didn't provide a solution so I'm posting one for future reference.
The problem was indeed that Amazon servers did not receive a refresh token from Google, thus making it impossible to refresh the access token after its expiration time of one hour.
Following this link and other Amazon forum posts, I got to a working solution.
Amazon Alexa developer console 'Account Linking' configuration:
Authorization grant type: Auth Code Grant
Authorization URI: https://accounts.google.com/o/oauth2/v2/auth?access_type=offline (even though the one from the google credentials was not v2, it shouldn't make a difference)
The access type is very important because, as documentation goes:
Set the [access_type] value to offline if your application needs to refresh access tokens when the user is not present at the browser. [...] This value instructs the Google authorization server to return a refresh token and an access token the first time that your application exchanges an authorization code for tokens.
Access Token URI: https://accounts.google.com/o/oauth2/token
Client ID & Secret: downloaded on Google Cloud Platform
Client Authentication Scheme: HTTP Basic
Domain List: google.com and googleapis.com
Default access Token Expiration Time: left empty
Now, after doing this and saving the configuration, be aware that you might not notice the change, as, from here:
When Alexa uses the refresh token to retrieve a new access token for an existing user, Alexa uses the access token URI that was configured at the time the user linked their account. Therefore, if you change the access token URI later, users who linked their accounts before continue to use the old URI for retrieving updated tokens. The users must unlink and re-link accounts to switch to the new access token URI.
So, in order to complete the procedure:
Deactivate your skill
Go to the Google third party applications that have access to your data and remove your Google Project associated
Reactivate your skill and login again (if done correctly it should ask you the permissions for the scope you specified in the Alexa developer console again
Done! after one hour you should re-try and it should have a renewed access token
Additional Info
I found that many suggested to retrieve the refresh token, I don't believe this is possible because, even if Google sends it, it's Amazon that stores it and uses it to refresh the access token.
EDIT:
This works fine for developing and testing but I discovered here that for publication purposes you must own the landing page that you redirect your users to. For me it was just necessary to create a simple HTML page hosted in a public S3 bucket that would redirect the request to the Authorization URI I wrote before, while the Access Token URI must remain the Google one.
Have you read https://developer.amazon.com/docs/account-linking/configure-authorization-code-grant.html ?
My guess is that the Refresh Token is missing because you have already auithorised the app. The RT is only issued once. Try going into https://myaccount.google.com/permissions?utm_source=google-account&utm_medium=web to revoke the permission and try again.
I have an issue with a web api returning HTTP 401 – Unauthorized when I use a Bearer Token to access it from a xamarin client. Either the iOS or UWP fail.
-This is an application that authenticates with Azure Active Directory to allow a user to login
-Once successfully logged in it gets a token that in turn is added to the web api request header
-The web api has its authentication turn on
The issue with azure settings
https://1drv.ms/v/s!ApPhjsvemKJggpR2ax5w4wRJcY7uXQ
the code
https://github.com/wleon12/XamarinForms-AAD-WebAPI.git
I cant seem to figure out what is wrong, appreciate any input or guidance
It depends how you protect the web API.
Normally, when we protect the web API using Azure AD, we will provide the the Audience and Tenant like this code sample. So that when we send the request with the token, the web API will verify the signature of the token and the value we config.
So for the 401 issue, please check the token you acquired with the value you config for the web API project. To check the Audience, Tenant and other values in the token, you can decode it from this site.
I am trying to implement server-to-server integration with Dynamics CRM Online 2016 and BizTalk 2013 R2. I am using the WebHttpBinding to call the CRM web API, which requires a bearer token supplied as an http header:
Authorization: Bearer [base64string]
I have written a client message inspector which calls Azure AD using ADAL to acquire an access token. This is secured with a client assertion certificate, which is assigned to the registered app in our AD tenant:
var token = context.AcquireTokenAsync(this.ResourceUri, assertionCert).Result;
ResourceUri is https://[myorganisation].crm4.dynamics.com
assertionCert is a ClientAssertionCertificate created using the app registration application ID and an x509 certificate in the machine certificate store that is registered to the app as a KeyCredential
This 'works' in that it returns a token and I can decode this token to inspect the claims - there are a fair number of them, I have no way of telling whether this is the set of claims that CRM requires.
The AD app registration is configured with delegated permissions to the CRM instance.
I have set the application ID in the CRM local user to that of the app registration.
Upon calling the webAPI and supplying this token, CRM responds with 401 unauthorized.
I have repeated the same process in a powershell script and in PostMan, all of which appear to show the same behaviour.
What else am I supposed to do to make CRM accept my access token?
edit #1: Tried hardcoding the authority URI to https://login.windows.net/[my-tenant-id]/oauth2/token rather than what comes out of dynamically acquiring the authority through AuthenticationParameters - this is the same value except ending with /authorization instead of /token. This makes zero difference.
edit #2: An administrator I am working with pointed out to me that the application user I am expecting to use had no user roles assigned - this has been amended to have a role which should allow API access, but this also made no difference.
edit #3: Set oauth2AllowImplicitFlow to true in the manifest for the app registration. This doesn't make any difference.
edit #4: Made some progress by creating a new app registration, this time as a Native app rather than a web app. I managed to get a token using a client secret, and this was accepted - BUT when assigning a certificate to the app, and presenting a ClientAssertionCertificate as before, I get the response from the authority:
Error validating credentials. AADSTS50012: Client is public so a client_assertion' should not be presented.
WHY? What does 'Client is public' mean? Just work!
Hrrrmph!
Turns out that the original situation I had tried and failed with, now works.
Web application registration with delegated permissions to CRM Online
Install a client certificate on the client machine, and register this same certificate to the app using New-AzureADApplicationKeyCredential
Link the app registration to a CRM Application User created for this purpose (they are fundamentally different to interactive users) - n.b. this screen is not easy to find
Call AcquireTokenAsync() from ADAL
Just works
I am at a loss to explain why this didn't work the first time I tried it, as CRM doesn't supply any information as to why token validation failed.
I am trying to build an AzureAD access app. I have to enable this app for external tenants. I have enabled external access on this app and it is configured to use the Graph API also. I have tested the app in the tenant in which it was created and everything(auth+ graph api access) works. Now here is the flow for the external tenant
I take the external tenant user to the grant consent URL of my app, the user(who is an admin of the external tenant) grants the access and i get the correct response
Now i want to get the authorization token for this user, so i take the user through the normal Oauth process via
https://login.windows.net/common/oauth2/authorize
followed by
https://login.windows.net/common/oauth2/token/
At this point Azure throws the following error
{"error":"invalid_grant","error_description":"AADSTS50000: There was an error issuing a
token. AADSTS65005: No permission to access \u0027https://graph.windows.net\u0027
resource is configured for \u0027d2037ff7-24e4-4cac-8e5e-16e370b36238\u0027 application,
or it is expired or revoked.\r\nTrace ID: 472aa92f-35a2-4ed9-ab07-
12488cc9e6f5\r\nCorrelation ID: b163dde5-eac5-4c82-99ad-0e1100487cb9\r\nTimestamp: 2013-
09-23 05:28:41Z","error_codes":[50000,65005],"timestamp":"2013-09-23
05:28:41Z","trace_id":"472aa92f-35a2-4ed9-ab07-12488cc9e6f5","correlation_id":"b163dde5-
eac5-4c82-99ad-0e1100487cb9"}
Why this error even when the app has been granted access. I tried to lookup the STS errors
but found no explanation. Any ideas?
[update]
SAML process continues to work for the external tenant however i.e I can use the app for SAML(SSO) login for this external tenant. The problem only seems to be coming for getting access to the graph API.
Try adding &prompt=consent or &prompt=admin_consent to the full authorize URL to re-request the user consent. My experience has been that the consent will be randomly revoked (maybe a bug) and will not ever be automatically re-requested (definitely a bug).