We have a webApi running under Asp.Net with Owin (.Net Framework 4.6).
Several native frontend clients (iOs, android etc.) are using that api.
That API currently uses Microsoft Login with bearer token and cookie authentication. This works, and the access token is returned directly to the webView in the client with the redirected requests and we are able to access our API with the Bearer token and another authentication cookie.
We have now the task to implement authentication with a LinkedIn auth provider in that API. For clearification: we need an OWIN implementation (no AspNet.Core).
We are able to get the access token from LinkedIn within the webAPI using this LinkedIn auth provider. So we see the token in our User.Identity.Claims. We are also able to return it to the client again. Yes, this is maybe no good idea, but it seems to be not possible to get the token directly in the browser/webView because the response_type=code is mandatory for linkedIn authentication. With response_type=token this works for the microsoft authentication.
Anyway at the end the webview is redirected to following url though we already have retrieved the access_token:
http://10.0.2.2:8108/signin-linkedin?error=unsupported_response_type
Please just ignore that we do not use https for now. The host is only for testing, but the important part is the appended error.
Why do we get this error? Who calls this request and why do we have that error though we have the token already?
Another information is, that the access token we have now in the client cannot be used for authentication against the webAPI. So we get back a 401 Unauthorized.
Maybe I should mention explicitly that we use also cookie authentication in the api, which seems to work as we receive the cookie in the webView and we are able to call methods that are protected with cookie authentication only in the correct user context.
Any help is highly appreciated!
The unsupported_response_type error is gone after using HTTPS.
Related
Is there a way to use the native WindowsIdentity/WindowsPrincipal inside of a C# application running on a corporate domain to be able to request a SAML token from the domain's ADFS server so that the C# application can then make subsequent calls to WS-Federation calls in a service provider that has been federated with the ADFS server?
Seems like we would use WIF to contact the ADFS server to get a token. Is there a way to supply a Kerberos ticket to the WIF, rather than using a username/password?
Looking at WindowsIdentity.GetCurrent() I can see that the user is logged in using kerberos, but don't see how to configure the WIF call to ADFS to use kerberos to automatically get a SAML token without a username/password set of credentials.
Does https://blogs.msdn.microsoft.com/alikl/2011/09/30/how-to-use-ad-fs-endpoints-when-developing-claims-aware-wcf-services-using-wif/ help?
You should make sure you have an endpoint enabled that can do windows integrated auth via kerberos enabled. Something like /adfs/services/trust/2005/windowstransport or /adfs/services/trust/13/windowstransport . You can check that via parsing the /adfs/services/trust/mex endpoint. Occasionally some of these endpoints are disabled by a sysadmin.
Using a kerberos ticket as the credential for the endpoint means your app needs to be running on corpnet with access to domain controllers so it can obtain a ticket for AD FS. If the app use is not required outside corpnet this might be OK for you. Else you need to consider how the app behaves/authenticates inside and outside corpnet.
Have a look at https://www.microsoft.com/en-gb/download/details.aspx?id=4451 for samples but they'll need modifying based on version of WIF you plan to use as outlined in https://learn.microsoft.com/en-us/dotnet/framework/security/guidelines-for-migrating-an-application-built-using-wif-3-5-to-wif-4-5
Lastly you should consider if its possible to use OpenID Connect and OAuth2.0 instead of WS-Federation/WS-Trust in your scenario. If yes, you should review the information at https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/overview/ad-fs-scenarios-for-developers
I have an asp.net core 2.0 program which has a MVC frontend using cookies/form based auth and some REST-ish web APIs which uses tokens. I have implemented a custom AuthenticationHandler for the web api that is token based etc. All in all the token based authentication works OK and access is granted or not based on the policy applied. The MVC authentication also works.
When the MVC Authentication fails, the user is redirected to the login page
When the Token Authentication fails, the result is a 401 Unauthorized
These are both fine.
The problem I have is that when I call the rest web API, and policy based authorization fails (eg, valid token does not grant access to resource), it falls back to the MVC 'form based authentication' scheme with an HTTP 200 code. I would prefer to have a simple 403 (not allowed) HTTP response. I have searched around but am not able to find a way to specify how the error is returned.
How can this be done?
I have searched the web over almost one week and I couldn't find a solution for the question.
I set everything on the azure portal for the authentication the claims and the principals are set that for sure after I checks it during the debug session. The only thing is missing! I cannot retrieve/get the jwt token from the below url.
The authentication is obviously successfully. I would be glad if someone can lighten me up on this.
https://dev.azurewebsites.net/.auth/login/done#token=%7B%22authenticationToken%22%3A%22eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdGFibGVfc2lkIjoic2lkOjJmMDg1ZWY1NDM0MzNlZDM1MzNkYTRkMDgyNGFlY2QyIiwic3ViIjoic2lkOmZjMzhmNGExZjI2ZDI5MTdhMTQzZWMyZDMyZjAwOWIyIiwiaWRwIjoiZmFjZWJvb2siLCJ2ZXIiOiIzIiwiaXNzIjoiaHR0cHM6Ly9kZXYtZjFhZGQwNGUtZjNjZC0xMWU3LWI0ZTktOWEyMTRjZjA5M2FlLmF6dXJld2Vic2l0ZXMubmV0LyIsImF1ZCI6Imh0dHBzOi8vZGV2LWYxYWRkMDRlLWYzY2QtMTFlNy1iNGU5LTlhMjE0Y2YwOTNhZS5henVyZXdlYnNpdGVzLm5ldC8iLCJleHAiOjE1MjA1Mzc1NTUsIm5iZiI6MTUxNTM1NzQ5MH0.z0Ys8dwKO_napvy4Ihfu39mHc6zyBpJIUjSzZWj8abI%22%2C%22user%22%3A%7B%22userId%22%3A%22sid%3Afc38f4a1f26d2917a143ec2d32f009b2%22%7D%7
If I create a new token from the principal it's working but I cannot get the data from the .auth/me service. I'm not using AD at all just google and facebook to authenticate.
The only thing is missing! I cannot retrieve/get the jwt token from the below url.
You could url decode your url and retrieve the authenticationToken property generated by your azure mobile app backend as the authentication token for your subsequent requests against your mobile app backend.
When decoding your authenticationToken jwt token, I found that the iss and aud do not equal your domain dev.azurewebsites.net.
If I create a new token from the principal it's working but I cannot get the data from the .auth/me service.
If you login via the browser (e.g. https://{your-app-name}.azurewebsites.net/.auth/login/{provider-name} e.g. facebook,google,etc.), after logged you could directly access https://{your-app-name}.azurewebsites.net/.auth/me via the browser. Or you could send the token along with your request as follows:
GET https://{your-app-name}.azurewebsites.net/.auth/me
Header x-zumo-auth:{authenticationToken}
And for non web browser based client, such as mobile, a JSON web token (JWT) would be presented in the X-ZUMO-AUTH header, and the Mobile Apps client SDKs would handle it for you. Details you could follow How authentication works in App Service.
Moreover, for generating the token by yourself, you need to correctly set the audience,issuer,signingKey,claim. Details you could follow adrian hall's book Custom authentication about the Post method under the CustomAuthController controller.
Meanwhile I realized that I tried to solve the problem from wrong direction.
I tried to get the token from the server Api App service I wrote. Instead of using one of the client library as Bruce told me. I missed the Javascript/HTML documentation part which was not in the main tree but under Cordova. I have only seen the Cordova, Android and IOS which was not good for me.
With the following link now I can get the token from the website with the Javascript client SDK!
https://learn.microsoft.com/en-us/azure/app-service-mobile/app-service-mobile-html-how-to-use-client-library
I have a AngularJS Web Application that requests data from API written in .NET Web API.
Now, I have ADFS 3.0 OAuth configured with my client ID and redirect URL(https://www.someredirecturl.index.html) utilizing Authorization Code Grant Flow.
I also have a .NET Web API that returns some values.
For e.g https://www.example.com/showData
Whenever, i call the URL, the ADFS Login screen shows up.
Then, the browser is redirected to my Redirect_URL with the authorization code. For e.g https://www.someredirecturl.index.html?code=xxxxxxxxx
Then, i capture the code and send it to the ADFS server( POST REQUEST ) to get the token.
Now, i have the token.
After this step, i should be able to call my API https://www.example.com/showData with Authorization Code: Bearer + token.
But, how does it work without writing anything at the server side.
Do i have to read the headers with key Authorization, extract the token?
What is the best way to do this?
At any point, will i see data on the browser directly, or it will always be called by some program sending headers.
What if www.example.com is a website. and www.example.com/api is a resource endpoint. How to merge the two of them. can user login to www.example.com when he would enter his credentials on ADFS. How to redirect from Redirect_URL with authorization code?
Yes - as per this.
Basically:
Check that the JWT is well formed
Check the signature
Validate the standard claims
Check the Client permissions (scopes)
jwt.io has a number of libraries that do this for you.
I am trying to wrap my ahead around using JWT to secure a WEB API written in C#, but am getting hung up on a few things. From my understanding the flow should be something like this:
Client provides username/password to the Web API from some client application (Angular, .NET, Mobile, etc)
The Web API validates that the username/password is correct and then generates a JWT (JSON Web Token) that contains the user's roles, information, expiration date, and other relevant information.
The JWT is sent back to the client application.
The client application hangs on to the JWT and sends it with future requests.
Assuming the above is correct (and please let me know if it is not), I am having trouble understanding the following things.
Once the Web API has validated the username/password and created the JWT, how does the JWT get passed back? Do I somehow add it to an HttpResponseMessage object? I can't seem to find a clear answer on this.
How should the client application pass the JWT back? Is this in the JSON data, appended to the URL, added to headers?
I see plenty of tutorials referencing OWIN and OAUTH. What are these and why do I need them? I am holding the user credentials and roles in the database used by the WEB API.
Once the Web API has validated the username/password and created the
JWT, how does the JWT get passed back? Do I somehow add it to an
HttpResponseMessage object?
Common practice is on success, the response from the service has the status code 200 OK in the response header, and token related data in the response body
200 OK
Content-Type: application/json;charset=UTF-8
{
"access_token": "NgCXRK...MzYjw",
"token_type": "Bearer",
"expires_at": 1372700873,
"refresh_token": "NgAagA...Um_SHo"
}
How should the client application pass the JWT back? Is this in the
JSON data, appended to the URL, added to headers?
Using the access token to make authenticated requests
Now that you have a token, you can make authenticated requests to the API. This is done by either setting the HTTP Authorization header or query string in the request depending on how the server is configured.
in a header
Authorization: Bearer NgCXRK...MzYjw
as a parameter
GET http://localhost:35979/v2/endpoint?access_token=NgCXRK...MzYjw
I see plenty of tutorials referencing OWIN and OAUTH. What are these
and why do I need them?
OWIN — Open Web Interface for .NET http://owin.org/
OWIN defines a standard interface between .NET web servers and web
applications. The goal of the OWIN interface is to decouple server and
application, encourage the development of simple modules for .NET web
development, and, by being an open standard, stimulate the open source
ecosystem of .NET web development tools.
OWIN OAuth 2.0 Authorization Server
The OAuth 2.0 framework enables a third-party app to obtain limited
access to an HTTP service. Instead of using the resource owner’s
credentials to access a protected resource, the client obtains an
access token (which is a string denoting a specific scope, lifetime,
and other access attributes). Access tokens are issued to third-party
clients by an authorization server with the approval of the resource
owner.