I am using facebook/twitter logged in user to authenticate my web api. i followed this
Okay that was most likely what I what. But my view page will be differently hosted. That is user will be logging in with a different page and they will send an ajax request get values from api controller.
I would authorize the web api only to user who is logged in.
If by "differently hosted" you mean on separate domains, then you won't be able to share a cookie between the two. If you mean that the client is a iOS app or Windows Phone app running on a device, the general pattern is to use a "Browser Control" and build a little UI as part of your API site. You can show your users this UI in the browser control and then scrape the token out. If you use Azure ACS, this is much easier with the "javascriptnotify" protocol that enables the token to be pushed out of the browser control.
The best article I've seen on this is http://www.cloudidentity.com/blog/2012/04/04/authenticating-users-from-passive-ips-in-rich-client-apps-via-acs-2
Related
Context
I'm building a hybrid native/web app. Part of it will be API driven, and part of it will be webviews showing an existing website.
Once logged in with my OIDC SDK (Amplify/AppAuth), I can access the user's id_token and access_token.
However, because the webviews used in the SDK are not controllable, I cannot reuse the cookies generated by my identity server.
Question
For the reason above, I'm trying to login a user from their id_token or their access_token. (both are JWTs)
I believe this isn't supported by IdentityServer4, but I am looking to implement something myself.
What I have found so far:
1) id_token_hint
OpenID Connect Core 1.0, Section 3.1.2.1, id_token_hint parameter:
OPTIONAL. ID Token previously issued by the Authorization Server being passed as a hint about the End-User's current or past authenticated session with the Client. If the End-User identified by the ID Token is logged in or is logged in by the request, then the Authorization Server returns a positive response; otherwise, it SHOULD return an error, such as login_required. When possible, an id_token_hint SHOULD be present when prompt=none is used and an invalid_request error MAY be returned if it is not; however, the server SHOULD respond successfully when possible, even if it is not present. The Authorization Server need not be listed as an audience of the ID Token when it is used as an id_token_hint value.
If the ID Token received by the RP from the OP is encrypted, to use it as an id_token_hint, the Client MUST decrypt the signed ID Token contained within the encrypted ID Token. The Client MAY re-encrypt the signed ID token to the Authentication Server using a key that enables the server to decrypt the ID Token, and use the re-encrypted ID token as the id_token_hint value.
According to this optional spec of OpenID, I should be able to use the id_token on the /authorize endpoint to login the user. I know this isn't implemented in IdentityServer4, but I'm looking at AddCustomAuthorizeRequestValidator to do that. However I'm not sure how to "get a user from their id_token" in the code. Do you have any pointers?
2) using AddJwtBearerClientAuthentication
This method sounds like I could authenticate from my access_token, but I can't find much documentation on how to use it.
THE PROBLEM
Let me know if I am misunderstanding requirements, but it feels like you have 2 different apps and are trying to make them feel like a single integrated set of screens.
The default behaviour will be as follows since web views are private browser sessions and cannot use system browser cookies. You want to prevent the second step since it is a poor user experience:
User signs in to the mobile app
Whenever a secured web view is invoked, there is a new private browser session with no auth cookie, therefore requiring a new login
COMMON APPROACH: SUPPLY A TOKEN TO THE WEB VIEW
It can be common to forward the mobile token to the web view, if the two apps are part of the same user experience. If required, extend the mobile app's scopes to include those for the web app.
You should not need to issue any new tokens or change the security model of either app. But the mobile and web apps need to work together on a solution.
POSSIBLE WEB VIEW SOLUTION FOR A SERVER SIDE WEB APP
This might be the simplest option:
Provide new .Net Core web back end entry point URLs that require tokens instead of cookies
The mobile app could then call those endpoints from web views, and supply its own token in the Authorization Header of the web view request
The web back end could then forward mobile web view requests to your Web APIs
The code to add the Authorization Header to a web view request may be a little tricky but there are ways to do it:
Android
iOS
POSSIBLE WEB VIEW SOLUTION FOR AN SPA
An option that works for Cookieless SPAs is for the web view to ask the mobile host app for an access token via a Javascript bridge. Some code of mine does this for a cookieless SPA:
Web UI Code to Call the Mobile Host
Android Code
iOS Code
You can clone / run the mobile github repos from your local PC to see the solution. I will be writing up some notes on this in my blog's Mobile Web Integration Post.
I'm building a mobile application (that might also later become a web application). The server side is a ASP.NET MVC + Web API application and I'm thinking about ways how I could implement the service's user management and authentication.
How should I implement the registration/login screen in the app? Offer native app forms, that will send just API requests to the service or is it preferable to show a web browser component and display the website's login page and then extract a token after the user logs in? I see the first option is more user friendly, but the second one will let me change the login / registration page (like for example adding external authentication providers) without breaking older versions of the app.
My second question is regarding the external authentication providers. ASP.NET Identity has good support for them and it is quite possible to let users register using Facebook or some other OAuth2 provider. Does it make sense to add support for external authentication providers when I plan to expose the app's API publicly? Are there any reasons why that is not a good idea?
Your first option is best if you believe your users will trust you to manage their passwords. You make a secure call to your service, have the service produce a bearer token as the result. That would be an anonymous call. I used the answer from this question to get me going down that path:
Get IPrincipal from OAuth Bearer Token in OWIN
If your users are less likely to trust you with their credentials, then the web view and external provider is a good alternative. You would need to work with providers that support the "Implicit Grant Flow" since don't want to share the apps clientid and client secret on the mobile device. This approach involves using a web view to login in, and then capturing the token on the client uri fragment on the response. I think it is on a location header, but don't have a working example in front of me. Something like:
https://your.domain.com/#access_token = 8473987927394723943294
you would pass that token with each api call afterwards .
Good luck!
Scenario:
I work on a portal application that has its own user credential store. Another company who has a mobile app needs to authenticate against our data store using SAML 2.0.
The user will launch the mobile app, it will send an authentication request to the portal/IdP, the portal presents login page, user logs in and a SAML response is then sent back so user can continue using mobile app.
My question: Is there anything else extra needed if a user clicks a link in the mobile app that requests a protected page on the portal? I mean, the user will be authenticated in the portal already, so it should let them right in without any other kind of token or whatever sent to the portal from the mobile browser - is that right?
Are there any other considerations or resources for referencing a situation like this?
Any assistance is appreciated.
There are two aspects that needs to be considered here: Authentication and Authorization. Even though the user is authenticated, s/he might not be authorized (i.e. have permissions) to access that particular link.
If you follow SAML 2.0 protocol that is OK.
You have just to be careful what are you sending with AuthetnicationResponse and how it will be used on mobile app.
There is not extra tokens. AuthenticationResponse (encrypted and signed) is token by itself.
I'm developing a web application that requires the user to log in using forms authentication. inside the webpage you need to download a desktop application that requires to login to the same system too. Is there a way to transfer the current logged credentials from the web application to the windows desktop application without need to login again?. Both applications shares a Login object from an vb.net interface.
I tried to save the IP address in the Database but that don't work for me because the website needs to be accessed inside and/or outside of the company and the user cannot login twice in different machines.
I tried to google for solutions but without luck.
Do you have any suggestions regarding this?
This may not be exactly the scenario you're envisioning, but this article shows how to use Forms authentication from a Winforms client using WCF Authentication Services. This should get you going in the right direction. Per the article, you can use these services in any .NET application.
http://msdn.microsoft.com/en-us/library/bb386582.aspx
This article shows how to do it with a Silverlight app, just so you have another example. http://blogs.msdn.com/b/brada/archive/2008/05/03/accessing-the-asp-net-authentication-profile-and-role-service-in-silverlight.aspx
And just one more for fun. http://aspalliance.com/1595_Client_Application_Services__Part_1.all#Page1
There isn't really any way to share this without encrypting a file containing the user's credentials and storing it on the hard drive along with the file, but then you run the risk of someone decrypting the information and getting access to the user's password.
I think that an alternate approach that could work is to generate an authentication token (could be as simple as a GUID) and store it in your database along with the user's id when the user requests the download. You would want this token to expire after a reasonable time limit (5 minutes, for example).
You could then include a file that contains this authentication token with the download. When your apps starts, you could check for the existence of the file. If it's there, you extract the token, delete the file, send the token prior to presenting the user login.
If the token valid, your server would send back the user's login and your app would proceed as though the user were logged in, otherwise you would just display the login screen.
I'd like to use OpenID to authenticate users on my webapp -- similar to how StackExchange does it. I'd also like to enable users of my website to use my Desktop and Mobile Apps using the same account. I've read this requires OAuth (OpenID is purely website only).
What I don't know is
Is this the correct approach?
What would the workflow for this be?
What data do I need in my database per user/OpenID? Do I store an "account" and then when they've authenticated with OpenID, I allow them to generate an OAuth Token for the mobile app?
In an ideal world, I would be able to have buttons similar to those on https://stackoverflow.com/users/login for both my WebApp and also in my Desktop and Mobile Apps which would simply allow users to login with their google or facebook account, is that possible? Simplicity for users is paramount, because my userbase will not take well anything remotely complex.
Can I use something like DotNetOpenAuth to provide all of this functionality?
Would a better solution be to break this up and allow users to authenticate to my site with OpenID and then I provide my own OAuth scheme for my desktop and mobile clients?
Probably the simplest mechanism is to embed a web view, and simply watch for navigation to a specific callback page and grab the authentication data that way. You should still be able to use OpenID for this.
What you should be looking into is Windows Identity Framework (WIF), it will work similarly for Web or Desktop applications using Claims-Based Identity. You would store an authorization token for each user (along with any other information you need) and you would get it in the Authorization Header of an authenticated HTTP Request. oAuth is the protocol for passing authorization requests and responses. WIF is a .NET toolkit to simplify this interaction.
For more info, check out the WIF home page and the following blog (not mine):
http://msdn.microsoft.com/en-us/security/aa570351
http://blogs.msdn.com/b/vbertocci/
This is the workflow that I came up with, and so far I think its working well.
The user is required to authenticate to the website via third party OpenID/Facebook/etc (mobile friendly website is available). Then, in their "profile" they can generate an API "key" which they can copy/paste into their client software. It isn't 100% transparent to the user, but its pretty good.