I was following custom authentication for my azure mobile app (https://www.newventuresoftware.com/blog/custom-authentication-with-azure-mobile-apps)
I created AuthControll which accepts username and password and creates token. When i call MobileServiceClient.InvokeApiAsync("Auth", loginInfoDictionary), I receive the user name and token succesfully. I created new MobileServiceUser(username) with received token an set it to MobileSeviceClient.CurrentUser. But When i call MobileServiceClient.InvokeApi over method which requiere authorization, it tells me i am unauthorized.
What i am supposed to do with received token then ? Can i use MobileServiceClient.InvokeApiAsync and MobileServiceClient.GetTable methods with this type of authorization ? If yes what i am missing ?
I found a problem in my solution on server side. I forgot to specify my url site when creating a token. Like this
var signingKey = Environment.GetEnvironmentVariable("WEBSITE_AUTH_SIGNING_KEY");
var audience = "https://TheSiteIForgotToSpecify.azurewebsites.net/"; // audience must match the url of the site
var issuer = "https://TheSiteIForgotToSpecify.azurewebsites.net/"; // audience must match the url of the site
JwtSecurityToken token = AppServiceLoginHandler.CreateToken(
claims, signingKey, audience, issuer, TimeSpan.FromHours(24));
Related
I implemented Token validation in .net core 3.1 application as below :
services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme).AddJwtBearer(options =>
{
options.Authority = Configuration["AuthorityUrl"];
options.Audience = Configuration["Audience"];
options.TokenValidationParameters = new TokenValidationParameters
{
NameClaimType = "preferred_username"
};
});
My main issue now which is security threat I believe that if the user passes ID token the authentication passes successfully which is wrong as Resource servers should accept only Access token. Is this behavior is right ? if yes how can limit the validation to Access tokens only.
Your API's job is to verify the attributes of the token - and APIs are typically configured with fixed values for items 2 and 3 below:
Signature
Issuer
Audience
Expiry
Scope
Use of id tokens should naturally fail if you check the audience (and you should) - where typical values are shown below:
Audience of access token = api.mycompany.com
Audience of id token = mywebclientid
APIs should also check for a required scope - and Authorization Servers do not include scopes in id tokens - since scopes are only used by APIs to protect areas of data.
In addition, some providers will provide a claim within the token to tell you its type, though this is vendor specific. As an example, Curity provide a 'purpose' claim - see the example at the end f this document.
I'm attempting to use the OWIN Open ID Connect middleware to outsource authentication for my ASP.NET application to Azure Active Directory. The application successfully redirects to the Azure AD sign-in page upon accessing a page that requires authorisation. However upon signing in to Azure AD I'm encountering the following error:
AADSTS90002: Requested tenant identifier '00000000-0000-0000-0000-000000000000' is not valid. Tenant identifiers may not be an empty GUID.
Here is the call to UseOpenIdConnectAuthentication. The tenant which is included in the Authority URL is f82d0e29-6018-43c6-b806-1f46a009ff4a. So why does Azure AD think I am passing in an empty GUID for the tenant?
app.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions
{
AuthenticationType = "AzureAd",
Caption = "Office 365",
Scope = "openid email profile",
ClientId = "e34401b2-6a9f-4547-9229-f0d93a33b1a1",
Authority = "https://login.windows.net/f82d0e29-6018-43c6-b806-1f46a009ff4a/",
PostLogoutRedirectUri = "http://localhost:44333",
RedirectUri = "http://localhost:44333",
AuthenticationMode = AuthenticationMode.Passive,
SignInAsAuthenticationType = signInAsType
});
There may be a bug in AAD right now. Another thread also started around the same time as this one: Empty GUID error when using Azure AD consent flow - According to one comment the AAD team is aware and looking into it.
UPDATE:
See my version of this question for the full diagnosis and solution:
Azure Active Directory passing empty GUID for tenantId with default template
Any ideas why this is. I have configured a Server Application and a Web API and an ID Token, Access Token & Refresh token is issued. However calling the userinfo endpoint return a 401 with the following header message:
WWW-Authenticate →Bearer error="invalid_token", error_description="MSIS9920: Received invalid UserInfo request. The access token in request is not valid."
The access token is valid according to http://jwt.io
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6IjVVbEw5a1JocDJNLUVzTDlBRDJOQ055aHZtdyJ9.eyJhdWQiOiJ1cm46bWljcm9zb2Z0OnVzZXJpbmZvIiwiaXNzIjoiaHR0cDovL3Rlc3Rsb2dpbi51bm9wcy5vcmcvYWRmcy9zZXJ2aWNlcy90cnVzdCIsImlhdCI6MTQ4NjYyOTUxOSwiZXhwIjoxNDg2NjMzMTE5LCJhcHB0eXBlIjoiQ29uZmlkZW50aWFsIiwiYXBwaWQiOiJrbnVkIiwiYXV0aG1ldGhvZCI6InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphYzpjbGFzc2VzOlBhc3N3b3JkUHJvdGVjdGVkVHJhbnNwb3J0IiwiYXV0aF90aW1lIjoiMjAxNy0wMi0wOVQwODozMjo1Ny4xNDZaIiwidmVyIjoiMS4wIiwic2NwIjoib3BlbmlkIiwic3ViIjoiM2krUGlyRncwSVlkdDVzTVNKQlpKbjVOTXZVWXZVdyt2WHI2Ujd1N0dBZz0ifQ.ajKtSk0xQE1crJkIA-lMLBZj2DtYE6xQo-Stmevh4pOGX17GEePbAFP-g6qPUwtGT_whVj74wRpSlyTBscp2JDsp_CW2E6BsTUI810S6jYRVjkYGxL1QcL1KoKJ8wyYKcxsCeOY2IUKNPnJOxV53Rs8E9EvJgjcsjTJHQw5Z_zC43dsTfCZvVfGrwJ3nn6BGxhIE_bEXvrWdgmg49V7-KK2kVDbDwJGr1iLpqU88-bkHdjGCIuc8XKX5pobWWlcyBmR_dpACM6Tu-d8jYJ_8mbof-eZrqn8YS61rgvRAhAAONyDklWcPgiYnhcMQVHZoCME-rVTjI6LDDY2czhL0rg
This question is asked long time ago but let me share my experience.
if you want to execute ADFS 4.0 userInfo endpoint(win server 2016) in a hope to get User profile but what i experienced is it return only Sub attribute
ex:
{
"sub": "MpR57wSIQz1kiR2uUMrkCQadbgDoztWmMV863Dugdso="
}
for anyone to try UserInfo endpoint you need to modify your application group, add api with Identitfier https://adfs.example.com/adfs/userinfo & at Client permission tab tick openId.
for execution of userinfo
Ex:
curl -X GET \
https://adfs.example.com/adfs/userinfo \
-H 'Authorization: Bearer ACCESS_TOKEN
Note: In your Acquire Accesstoken code you need to pass your resource = urn:microsoft:userinfo
The ADFS userinfo endpoint always returns the subject claim as
specified in the OpenID standards. AD FS does not provide additional
claims requested via the UserInfo endpoint. If you need additional
claims in ID token, refer to Custom ID Tokens in AD FS.
I've only done this once so I don't have much suggestions to make yet. So I cant make any suggested unless there is more detail.
You should try and get more evidence from the AD FS side. Enable debug logs using
wevtutil sl "ad fs tracing/debug" /l:5 /e:true
Do the repro and then disable logs as follows.
wevtutil sl "ad fs tracing/debug" /e:false
Then export the logs to view using
wevtutil epl "ad fs tracing/debug" c:\temp\userinfoerr.evtx
Open that event log in event viewer and have look and see what other errors are reported around validating the JWT.
I'm trying to query a Firebase database from a Service Worker using the Fetch API. However it doesn't work as expected as I can't get authenticated correctly.
Basically what I'm trying to do is from origin https://myproject.firebaseapp.com inside a Service Worker I do a call like this :
var fetchOptions = {};
fetchOptions.credentials = 'include';
var url = options.messageUrl;
var request = new Request('https://myproject.firebaseio.com/user/foobar.json', fetchOptions);
messagePromise = fetch(request).then(function(response) {
return response.json();
});
I'm getting this error :
Fetch API cannot load https://myproject.firebaseio.com/user/foobar.json. Response to preflight request doesn't pass access control check: Credentials flag is 'true', but the 'Access-Control-Allow-Credentials' header is ''. It must be 'true' to allow credentials. Origin 'https://myproject.firebaseapp.com' is therefore not allowed access.
Any idea of a way to fix it? How one should do to query/update the Firebase database from a SW?
I've read https://jakearchibald.com/2014/using-serviceworker-today/ and one of the gotcha was exactly that problem, the fact that Fetch request do not send authentification.
Ideally it would be great to be able to use the Firebase JS API inside a SW but this doesn't seem to work as well.
Firebase doesn't store authentication info as a cookie or in anything that would be sent along in the credentials, so there's no need to send them in your fetch request. Instead, you'll need to pull the token from Firebase Auth:
firebase.auth().currentUser.getToken(true).then(function(token) {
// token is the value you'll need to remember for later
});
Once you've got the token, you should be able to add it as a query parameter to the REST request e.g. ?auth={THE_TOKEN}. This will allow you to make your authenticated request in the Service Worker.
I'm trying to obtain a token from ADFS to that I can use it with an on-premise Windows Service Bus installation. I may not have ADFS properly configured because I get the following message:
MSIS3127: The specified request failed.
The code to access the token is as follows:
string adrecaSTS = "trust/13/usernamemixed";
WS2007HttpBinding binding = new WS2007HttpBinding();
binding.Security.Message.EstablishSecurityContext = false;
binding.Security.Transport.ClientCredentialType = HttpClientCredentialType.None;
binding.Security.Message.ClientCredentialType = MessageCredentialType.UserName;
binding.Security.Mode = SecurityMode.TransportWithMessageCredential; //https
string baseSSLUri = #"https://<myadfs>/adfs/services/";
WSTrustChannelFactory trustChannelFactory = new WSTrustChannelFactory(binding, new EndpointAddress(baseSSLUri + adrecaSTS));
trustChannelFactory.TrustVersion = TrustVersion.WSTrust13;
trustChannelFactory.Credentials.UserName.UserName = "username";
trustChannelFactory.Credentials.UserName.Password = "password";
WSTrustChannel tokenClient = (WSTrustChannel)trustChannelFactory.CreateChannel();
//create a token issuance issuance
RequestSecurityToken rst = new RequestSecurityToken(RequestTypes.Issue);
//call ADFS STS
SecurityToken token = tokenClient.Issue(rst);
The endpoint is enabled on ADFS and my client (laptop on separate domain) trusts the certificate from ADFS.
Do I need to set up some kind of trust or something further? This error message is not particularly helpful.
See here:
https://github.com/thinktecture/Thinktecture.IdentityServer.v2/blob/master/src/Libraries/Thinktecture.IdentityServer.Protocols/WSFederation/HrdController.cs
The ValidateToken method has most of the code - but you first need to extract the InnerXml from the generic token and turn that into a SAML security token (again using a token handler).
Found the issue. I was trying to log on as an administrator account. When I used a regular user it worked.
I also had to modify the RequestSecurityToken to have a KeyType of KeyType.Symmetric
I see that you solved your issue, but here is some additional inforamation to potentially help others that might have the same error message but a different cause.
The AD FS error, "MSIS3127...", can have multiple causes. For us, it was caused by one of our relying party claim rules specifying an AD FS attribute store that didn't exist.
In order to debug the error, we checked the Event Viewer on all of the servers running AD FS, and that's where we found the detailed message that called out the attribute store problem. So, if anyone else gets the same error message, then I suggest checking the Event Viewer on AD FS to see if there are additional logs.
Note that AD FS logs to the Event Viewer under the folder/node of Applications and Services Logs => AD FS => Admin