I recently was tasked to implement Single Sign In functionality where users could register and sign in to this site using their credentials from a more popular site. That got me to start looking and asking around as to who was doing Single Sign In. I was surprised to learn how much of a hot button topic it turned out to be.
If you have rolled out Single Sign In for a web application, then which authentication providers did you end up using and why?
Try OpenID, stackoverflow uses it as well.
OpenID is very good if its an internet application. Lets users use things like their google account to log into yours.
If it is an intranet application then Windows Auth is fairly common but it works best with IE.
Related
I'm having trouble understanding how ASP.NET Core authentication works.
I want to implement JWT access token authentication with refresh tokens. To my knowledge, this is the industry standard for authenticating a client (Mobile app, SPA Web application). For security purposes, I'd prefer to not implement my own authorization logic including JWT generation and refresh token handling. Since ASP.Net does not natively support this, Naturally my choice would be to use IdentityServer4, a large open source library for handling this kind of stuff.
However IdentityServer4 is heavily based on OAuth, and I'm not sure how that works with SPA applications and mobile apps (clients I trust). It requires the client to redirect to some arbitrary webpage to enter their credentials and then redirect back to the app. Gross. I've never seen a major app like Snapchat, Instagram, etc. have this kind of authentication flow where you are directed to some webpage/browser during the login flow. Luckily IdentityServer4 has a little feature to handle username/password authentication for my trusted clients (http://docs.identityserver.io/en/latest/quickstarts/2_resource_owner_passwords.html)
Great, that seems to suit my needs. But... Now I want to add Facebook Authentication. IdentityServer4 allows for External Authentication, however it is still cookie based (to my knowledge). Which requires the Android/iOS/SPA app to redirect to a webpage and then redirect back to the app. Again, this isn't ideal from a user perspective. Facebook provides native mobile SDKs to handle this type of authentication which returns an access token so there is no need to redirect to web pages using cookies.
Now lets say my iOS app uses the Facebook SDK to grab an access token for the user and sends it to the backend. The backend validates the token against the Facebook SDK, and subsequently registers a local user in it's own database.
Now when that same iOS user tries to login to the app, the app will generate a facebook access token for that user from the SDK and send it to the backend. However I'm not sure how to utilize IdentityServer4 to generate a JWT for the user since I need that users' username and password. This is where I'm stuck. I seem to be fighting against the library which makes me believe I am severely misunderstanding something.
TLDR; IdentityServer4 seems to be heavily based on cookies which doesn't really fit nicely into mobile apps/SPA webpages when you are redirected back and forth from authentication webpages. Am I using the wrong tool for the job? What are some alternative solutions?
As a note on big social apps: I think it comes down to who keeps the passwords. Facebook, Instagram, Snapchat, Google act as identity providers to third parties. They themselves require user to register and specify the password which they keep. Therefore they can use any customized approach for handling validation with those passwords. However, if any of them offerred a posibiltty to log-in with the other I.e Instagram were allowing to sign-in with Amazon credentials, then they would need to follow through a standard way like OAuth and redirect to the third party for log-in. Last time I checked Instagram, Facebook and Snapchat only offer to register and no option to sign in with 3rd parties which explains why the don't need redirects.
Now if we establish that a redirect is a necessary evil, then the means to carry over the data accross aren't that numerous. I.e. we either would need to pass data via a query string or use cookies. Am I missing any others?
Both have limitations but since cookies are persisted and browser carries them automatically with each request, they do seem like a better option for the job, especially if multiple redirects are required for an external IdP to track the state of authentication request. The same reason is mentioned here:
http://docs.identityserver.io/en/latest/topics/signin_external_providers.html
It's absolutely the right tool for the job if you want what OpenID Connect and OAuth2 give you. It sounds like you may need convincing though and it may be that your use case doesn't need the full breadth of functionality offered.
If you have multiple client applications and APIs in play then I think using OpenID Connect and IdentityServer4 the right choice at this point in time.
Regarding native apps, you used to word "gross" to describe using the user's default browser to perform the sign in process and it's understandable why you might think that at first but it's not as bad of a UX as you'd think and has plenty of advantages:
The client application is completely decoupled from how authentication is actually done be that federation, social sign in (Facebook in your case), multi-factor, retina scan etc. Your identity server deals with all that complexity and is a single point of management (and failure - so make it highly available!)
Single sign on is possible - if they're already signed into your IDP then they can go straight in (although you have full control of the flow - want them to consent or confirm the sign in request every time - you can do that)
If the user has a password manager set up in their browser then that'll work too
Both iOS and Android offer APIs for doing this stuff and the work well. If you skin your native and web UIs to look similar the flow from a user's PoV is not jarring at all.
You can still use refresh tokens (ultimately secured by the platform) so you don't actually have to do the interactive flow very often anyway.
Some additional reading below. Quite a lot of thinking has gone into this from the industry so it's definitely worth digesting the current best practice.
https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html
IETF current best practice: https://www.rfc-editor.org/rfc/rfc8252
Don't make Scott hate you ;) : https://www.scottbrady91.com/OAuth/Why-the-Resource-Owner-Password-Credentials-Grant-Type-is-not-Authentication-nor-Suitable-for-Modern-Applications
For client side SPA browser apps OIDC provides the implicit grant type and uses a silent refresh and IDP session monitoring mechanism to maintain the session. Check out the oidc-client-js library which implements this approach.
I have been doing a lot of research into how to authenticate mobile apps with an API - I still feel a bit unsure about which flow & architecture would be better to use in my particular use case.
I think what's confusing me is some of the terminology used.
My use case:
An API & database on one server. Which holds the users & and the users resources.
A web app, which I have built and consumes the API. Hosted on the same server as the API. So it's dogfooding.
A web app, which I have built and consumes the API. Hosted on a different server to the API.
A mobile app, which I have built and consumes the API.
I'd like to be able to authenticate with the API using username & password.
The API will never be opened up for consumption by other 3rd party services except the web app and the mobile app.
Initially I felt like using the Resource Owner Password Credentials Grant flow would be sufficient. However in the docs it states that this flow should be used if "The client is absolutely trusted with the user credentials".
Since both my mobile & web apps will be built by me, I'm assuming they are seen as 1st party clients. Therefore am I right in thinking they are considered to be trusted with the user credentials? As I typically thought that when implementing oAuth, the idea would be to have the authentication server separate from the resource server. Which would allow you to have one authentication server for multiple APIs.
After reading this post: Why the Password Grant is not suitable for modern applications
It threw me off track a bit. But then, is this post talking about using this flow in my use case?
I was also looking at the Implicit Grant Tokens flow. However using this flow I couldn't really see how the user would enter their credentials first?
I also question if any of the oAuth flows is really needed for my use case and I should instead look at other ways of authenticating?
I'm really quite lost with this I would like some direction to go in with how to authenticate users in my particular case.
Thanks in advance!
I'll most likely be using Laravel to house my API and so I do have Passport available to me to implement oAuth
EDIT
From following this oauth article I've found that in all use cases of my app, I end at Password Credentials Grant flow. Would I be correct here?
I want to implement OAuth/OpenID for Website One and use it in Website Two.
I create Sign Up, Sign In, Sign Out, Profile functionality/Pages for Website One and want to use authentication in Website Two like Facebook or Twitter authentication.
As an additional information if you got interest you can visit trial websites of Website One and Website Two. Please do not expect full or correct functionality because as I said above they are just trials yet.
P.S.
I decided to use OAuth. Forget about OpenID.
I had a look at your sites. It's not working this way.
You want STOZE to use the authentication from TIKSN? Well, you have to configure STOZE as an "oAuth resource server", so it keeps the protected resources, and configured to work only with token he gets from TIKSN, which will be configured as an "oAuth identity provider".
Read a little bit about oAuth...
OpenID is a different story - then, you will have to configure TIKSN as "OpenID provider", and configure STOZE to enable it to work with OpenID providers (so TIKSN will be one of them, but you will be able to use also Google, Yahoo, etc)
Read a little bit about OpenID...
HTH
I want to use google/yahoo ids to be used to login to my website.
As its done in stackoverflow.
Can any one provide me a starting point.
That authentication method is called OpenID. You can get details at the open id website.
If your webiste uses PHP on the server, here's a resource to get you started with OpenID and PHP
UPDATE
Since I've posted this, the world of open federated authentication has evolved quite a bit. If you're interested in this you may wish to look up OAuth v2 online, or check out these links: www.oauth.net and the Google resources on OAuth2 available here.
OAuth builds upon the concepts of OpenID and it expands the functionality quite a bit, in particular in the areas of not just providing authentication but also providing authorization for applications using a centralized provider of the user's choice (i.e. Google, Facebook, Twitter or your own :) )
I have been using JanRain for the same thing. It is free and integrates with loads of different login providers, such as, Facebook, Twitter, Google, OpenId (generally), yahoo, msn, and many more.
There is code that lets you integrate it with almost any programming language/platform you want.
try this sample in CodeProject.
http://www.codeproject.com/KB/web-security/OpenIdFormsAuth.aspx
It worked fine with me.
I am working on designing an api/application structure to mimick facebook's for a project of mine. I am wondering what the best way of going about authenticating users is.
For an app how do I give them the nessecaru credentials and how do I authenticate those credentials?
I would investigate these technologies before I started down the road:
OpenSocial this is basically the "open source" facebook platform. You can set up your site as a container, or an application (or some funky combo of both).
OpenID if you just want to be able to authenticate people using their login credentials from another trusted site
OAuth if your looking for a API style authentication framework
All of these techs have reference implementations in the usual suspects and are supposed to be more "open" than anything facebook is doing. We will see what happens in the long run...
Well the facebook api actually has an open source implementation so that's fine. But I'm wondering how does facebook actually authenticate everything? Like how do they pass user data to you?