I am trying to research what options are available when using 3rd party authentication for a web application. I would like to have the ability to customize which information is submitted when a user authenticates as well as control the branding of the login.
I would also like to be able to manage how password recovery/reset is handled.
Any suggestions?
EDIT: I wanted to add more information to detail what I was looking for. Essentially and am wanting to hand off all the password reset, authentication, and management to a third party. Just like OpenID. However, I don't want to user/customer to have to go to an OpenID provider as I think it could be confusing. I would like them to enter a username and password on my site but be authenticated by another provider. Does that make sense?
If it's helpful still, I compared (5/18/2015):
Auth0
AuthRocket
UserApp
DailyCred
Conclusion for me was Auth0, because while all the features are very similar, it felt the most legitimate, as in it's not a start-up that might disappear in a few months. Now, the reason that was super important for me was because login is a foundational requirement, so I need to believe as a customer that the Authentication as a Service will be up for as long as I will be.
Here's the full comparison story:
https://medium.com/#bsemaj/authentication-as-a-service-comparison-5-quick-lessons-for-b2b-businesses-e7587275824c
Related
I have read a lot about OIDC and OAuth2, I know the id token is mainly used for the client to know who the user is and whether the user is still online currently.
Furthermore, Id token can prevent a class of impersonation attacks [You can find more details in this article].
But what if the id token is stolen? Can the attacker uses the id token to impersonate a user?
In our project, we just ensure https besides the OIDC. What else security consideration should I take to mitigate the impersonation attacks?
The goal or purpose of OIDC is not to be more secure than OAuth2, and this kind of comparison doesn't make sense. They solve different problems.
Let's start with OAuth2. In very short and somewhat simplified, OAuth2 solves the problem when a website holds data of a user, and that user wants to grant access to some of their data to another website. Say you have a Facebook account, but want to allow my application to access some of your data on Facebook, or for a more concrete example, you want to allow my awesomeapp.com app to post a link to your Facebook wall. For this, my website redirects you to Facebook, you log in, get an access token, and send that access token back to my website so that I can use it in your name to get what you allowed me to.
Note that there is one thing missing. I have no idea who you are. I just had an access token, with which I can do stuff, but I don't have identity info about you. Sure, this can be abused in different ways, the access token can hold your email address or whatever, but it's limited, the size matters, and there is no standard way.
At least not until OIDC comes in the picture. OIDC provides the identity element.
The purpose of the ID token is to provide identity info, to tell me claims about who you are. It may claim what your email address is, what security groups you are in, which company you work for, or anything else. Also it may be used to download more claims, in case they don't all fit in the actual token (see userinfo). These claims come from the Identity Provider, say Facebook, which my application then has to trust of course, i.e. I will believe whatever Facebook tells me about you.
This is all possible with pure OAuth2, but there is no standard, well known way to do so (or well, it is OIDC :) ). You could invent and implement something yourself, but these things are more complicated than they may first seem to be. That's why OIDC was invented, so you don't have to. But after all, OIDC is just a way to use OAuth2 to provide identity. In the end, it's just an extended OAuth2 if you like.
As for what security considerations you need to take into account - this part of your question is way too broad and can't be answered unfortunately. Security is a very complex topic.
I'm not really a security purist so my additions to Gabor's points are from a more practical viewpoint, as someone responsible for building well architected UIs and APIs:
An id token represents proof of authentication to a UI
An id token is NEVER used by APIs, which must use access tokens instead
An id token is the only type of token a UI should ever read, and it is mandated to have a JWT format
For Web UI logins an id token provides extra security, since it enables the UI to validate tokens and protect against some types of token substitution attack - so yes - OIDC is more secure
An id token is sometimes needed in order for logout to work
You should ALWAYS use a certified security library that does this type of work for you, rather than reading tokens directly in your own code.
A bit of background may help. I'm looking to authenticate a user using SAML, but I want to maintain the look-and-feel of the login experience to the best of my ability. I've looked into OpenSAML a bit, but not extensively since I'm not sure this can be done yet. So, if I have a login service that can retrieve the username/password from the user, can I programmatically issue a SAML request to an IdP to authenticate said user without having to go through the entire XHTML form processing steps?
Your question is more about how to Authenticate the user and less about SAML. SAML doesn't really dictate how a user gets authenticated at the IDP and it definitely doesn't handle your use case. As a 3rd Party SAM SP, it is not recommended you ever prompt a user for their credentials for security reasons since Enterprises only want users entering credentials into "Corporate branded" login pages to reduce phishing and other password based vulnerabilities. Besides, how can your customer trust that you are not storing users passwords if they are entering them on your site? Let the IDP handle the user login, it is just one of the many benefits of using SAML. HTH- Ian
I was thinking about security for my REST web Service API, and decided to take a look at others large services and how they do it. As an example I decided to study Twitter's OAuth. After reading beginners guide I'm a little be confused and shocked.
As I understood it's Service provider responsibility to authenticate user and to show User what kind of access consumer is demanding (for example it want's read only access to specific resource). But I saw service providers that doesn't inform user on what type of access consumer is demanding (and even now showing consumer's identity). The second part of problem is that consumer can show his own custom Provider Service Authentication form in IFrame, and just hide access details, they can just steal you password, or request unlimited access to you resources, they can do basically what ever they want, there are lot's of way to trick user.
As an example let's take a LinkedIn. They request your gmail username and password inside their own form, and you have no idea how they will use it. They can just steal it and store in their DB, they can OAuth with it to gmail (and they don't show gmail's page with information what type of access they request), they can do whatever they want with this information.
What I'm trying to say is not that OAuth communication protocol is not secure, but rather there are lot's of way to use it improperly to trick the user and get his credentials.
BTW there were some security flaws in OAuth protocol itself: (http://oauth.net/advisories/2009-1/) and I'm pretty sure there are more, but no one cares to find them.
I'm going to go with 'You didn't understand it.' (In your defense, very few people do.)
Let's be clear: The session fixation attack you're referring to affected OAuth 1.0, but was resolved in OAuth 1.0a, which became RFC 5849. There are no major implementors of OAuth 1.0 — the major implementors all either implemented OAuth 1.0a/RFC 5849 or they implemented one of the OAuth 2.0 drafts.
As for the username/password anti-pattern, OAuth 1.0a does not provide for a mechanism to exchange a username and password for an access token. OAuth 2.0 does, but only for the purposes of supporting installed applications. Keep in mind that an installed application could simply keylog (or similar) if it really wanted to. When it comes to security, all bets are off if an application is already running natively and unsandboxed on the client's machine. But this is actually a very different scenario than what you're talking about. Web applications in both OAuth 1.0a and OAuth 2.0 don't ever touch the username and password.
The flow for OAuth 1.0a goes like this: The application asks the provider for a request token, telling it all of the things it wants access to. The provider issues the temporary unauthorized token, at which point the client may send the user to the provider to authorize that token. The user logins in with their username and password on the provider's site and then either grants or denies access. The provider then redirects back with a verifier string that allows the site to upgrade to an authorized access token. All of these interactions are signed. If the signatures don't match on any of them, the provider will reject the request. And the user can revoke any token at any time, removing the client's ability to access their account.
There are a number of security considerations with the protocol, but if you actually read the list, it's essentially the same list of the security issues that affect almost every site on the internet. These security considerations are all very well known and very well understood. To my knowledge, there are currently no known exploitable attacks against providers that correctly address all of these security considerations.
Point being, you are much safer using OAuth 1.0a or OAuth 2.0 to authorize a third party than with any of the alternatives. If you don't feel comfortable with these, the solution is simple: Don't authorize third parties to access your account. There certainly are plenty of reasons why you might not want to do that.
It sounds like you are confused about what's not secure. As I understand it, the OAuth protocol itself, if implemented properly, is secure. It's just that it's easy to implement improperly, and users get confused because they don't really understand what they are doing.
For example, what LinkedIn is doing is all wrong. I would never give them my gmail account information in this way. In order for me to provide my gmail account information, I insist on seeing that my browser is using SSL with Google and so the root frame of the page comes from Google.
Then there is the matter of trusting Google to correctly tell me what access is being requested and by who. If I don't trust them to do this, I shouldn't be using OAuth.
Since I have never used openID befor I have no idea about it.
I want to know when someone want to log into my website using openID do I have to register his information (is there any registration process efen if the user don't fill the information).
should I provide an alternative classical user registration beside openID.
The best OpenID login experience has no user registration. You accept their OpenID and you and your user are both done. Talk about lowering the barrier to joining your web site. It doesn't get much easier than that! If you must gather more information about a user besides just their OpenID claimed identifier, and this is a general rule with user registration: keep it minimal, and preferably don't ask for the additional information until the user actually requests a service that requires that you collect that particular data. This helps keep the user interested in your site and doesn't drive him/her away.
And if you're writing a new web site, I highly encourage you to not accept username/password anti-pattern. If you do your OpenID login right (today that probably means making big, prominent Google and Yahoo login buttons and then a smaller OpenID button that makes a text box appear) then users won't get confused. Before OpenID, lots of sites had "Login with Yahoo!" buttons on their sites and users "got it". OpenID can look just like that and be easy for the user.
By not offering a username/password style login, you somewhat force the user (with your ultra-easy OpenID login) to start getting used to not reusing an old or inventing a new password at your site. We as webmasters must train web users to stop giving their private passwords to so many web sites.
Our solution was to run our own openID provider and not tell anyone. If you choose to sign in without openID you get redirected to a very locked down openID provider. This was great as we started with 1 site and now have 4 and they can all share accounts. Our provider will not let you use it anywhere else (can't login here with it).
Opinionated Rant
My opinion will almost certainly be unpopular; but I'm going to make it anyway, 'for the good of privacy' :)
OpenID is not a great idea; typically in computer security it is considered bad to have a single account for everything, as if that account is compromised the person can compromise all services attached to it.
OpenID violates this quite directly.
As well as this, it creates a single point of failure, and if the protocol is shown to have a flaw [removed incorrect reference to OAuth flaw] it means you are susceptible everywhere.
Now it goes without saying that OpenID provides convenience; and sure it does, but for mine, the cost of this is too great.
Personally, I was a bit frustrated to note that OpenID was the only way to sign up to this site; so I would suggest to you that you provide an alternative mechanism (and if it were me, I would not implement OpenID at all).
Summary
Yes. Provide alternatives (IMHO).
you can do like stackoverflow website, new user will be unknown until the user fill his information, and in your website you can disallow the user from posting if he didn't complete his profile info.
should I provide an alternative
classical user registration beside
openID
yes you should provide because maybe the user don't have openID registration or he know nothing about openID tech.
Is OpenID a secure method of authentication users on a website?
And, if not, what are the security risks associated with OpenID?
I agree with many of the points David makes above, so I'm making some points here just for the sake of argument.
For the knowledgeable user, I would argue that OpenID is a more secure form of authentication than many websites provide. Now let me back up that statement. First what do I mean by a knowledgeable user? I would define that person as somebody who is aware of the weaknesses of OpenID and who takes measures to mitigate them:
Maintains multiple personas if they don't wish websites to be able to track them effectively.
Registers two or more OpenID providers at websites where 24/7 access is an issue.
Always logins to their OpenID provider directly. They never login to a page a 3rd party web site has redirected them to.
Many websites do not know how to securely maintain user's passwords. The really nice thing with OpenID is that I get to choose my OpenID provider and thus the level of authentication needed to login to a relying party. For example, I can choose to delegate authentication to Verisign or Trustbearer - both of which provide much stronger authentication techniques than most websites on the web. I would much rather trust an organization which specializes in security with my password than some random web site on the web. So I would argue, that for the knowledeable user, OpenID can be more secure than each website implementing their own authentication system.
All that being said, most users are not aware of the risk factors inherent in OpenID and won't take the steps to mitigate the risks.
Actually I always disliked OpenID for various reasons.
I have to trust the OpenID provider who I gave my data. I do trust certain sides to certain degrees, but just because I may trust Stack Overflow, I don't automatically trust any of the well known OpenID providers.
If my OpenID password is compromised, all my sites where I'm using OpenID are compromised. Usually I would chose a different password for every site I'm using, but I can't with OpenID.
I don't like the Persona concept at all. Even though I'm asked before any data is sent, it just doesn't seem right that one provider has this information and other services can request it. Okay, I don't have to use it if I don't like, but the concept seems flawed to me.
As has been mentioned already, data is sent between a site and the OpenID provider and back again. Whenever data is exchanged, it can be compromised. No system is 100% secure; not even SSL (HTTPS). It's a difference if data only travels from me to a side and back to myself or if it also travels from that side to another one and back again.
If an OpenID provider is hacked and the hacker gets the login data of all users (after all they are lovely centralized in one place!), just think of the impact!
Just to name a few. I also fail to see the big advantage of OpenID. For the user they say
Faster & easier registration and login
Reduced frustration from forgotten user name/password
Maintain personal data current at preferred sites
Minimize password security risks
Okay, let's analyze that.
(1) How often do you register for a page a day? 200 times? If I register for 2 pages a week, that is already a damn lot. Usually rather for 2-3 a months at most (actually Stack Overflow, or my OpenID provider to use Stack Overflow, was the last page I registered and this was not quite yesterday). So when you register for 2 sites a month, you don't have the 5 minutes it takes to fill out a form? Come on, don't be ridiculous.
(2) How? Because it uses the same password everywhere? "This is no future, this is a bug", most security experts would say. Or because it allows me to recover my password via mail? Well, actually almost any side I use allows me to do so. Despite that, my Firefox remembers my passwords quite well, stores them encrypted on disk (using a master password) and this encrypted database is back-uped regularly to never get lost.
(3) Well, this is probably something positive... however, my name has never changed so far, my e-mail address won't either as it's one of the domain I use and forwarded to a real address (so the real one can change, I just update the forward and everything works as before). My street address? Well, some people move a lot. I only moved once in my whole life so far. However, most sides don't need to know my street address. Sites where I see no reason for having the people know this information, but that demand me to fill it out for registering, just get a faked one. There are very little sites on the whole Internet that know my real address (actually only those that may ever have to send me a snail mail or where I might order goods).
(4) Actually I see it the other way round. It maximizes the security risk. How would it minimize the risk?
OpenID is inherently insecure. It works by your site redirecting the user to their open ID provider site and then accepting an ID back from that site. This provides insecurities in both directions. You have to trust the ID that comes back (as you have no way of authenticating the user yourself) and it is easy to operate a proxy to the user’s open ID provider, that allows you to steal their username and password.
OpenID is fine for something like Stack Overflow, where it doesn’t really matter if someone impersonates you. Using OpenID for sites with more serious – on a personal level – content is extremely risky. If you use OpenID for your email for example, then anyone stealing your Id can access your email. They could then in turn send password reminder requests to other sites that you use in order to get passwords for those sites. In the worst case, you could use OpenID for a bank account, or have a bank that sends password reminders to your email account...
There are numerous other security problems with OpenID. You can find more information in "Privacy on the Internet".
OpenID does add another party to the authentication process which you must treat as a trusted component. It's quite similar in that regard to any application that allows account recovery by e-mail, but whereas your email messages are transmitted in cleartext, you may choose to communicate with OpenID providers only over verified HTTPS connections.
Review the Security Considerations section of the specification.
For a great description of the weak spots in OpenID and a demonstration of how a good OpenID provider can give an experience that's much more secure than the traditional easily-phished password, see this short video by Kim Cameron from his Identity Weblog.
OpenID can be made more secure if you choose to ignore all OpenID providers that do not support HTTPS
I think the main weakness of most OpenId providers is that they offer password recovery via e-mail. That reduces OpenId security to the security of my e-mail provider. If someone gets access to my e-mail account he can effectively steal my identity (with or without OpenId).
Using OpenId for authentication makes stealing ym identity just easier. Just get access to my e-mail account and reset my OpenId password. Nothing more to do (instead of 100 password reset requests, one for each of my accounts on the web).
Even worse, if the attacker changes my e-mail account's password it will be very hard for me to prove that I am the original owner of that OpenId account. The attacker might change the associated e-mail account to his one so I can't reset the password even if I get back my e-mail account later.
It might be enough to get acces to the password recovery e-mail my OpenId provider sends to steal my identity.
OpenId providers musst offer disabling e-mail password recovery and provide a more secure way to recover a lost password. Something based on postal address, passport or bank account (things I trust more than an e-mail account).
As long as an OpenId account can be taken over by just getting access to a single e-mail it's nothing more than an additional single point of failure.
See also: http://danielmiessler.com/blog/from-password-reset-mechanisms-to-openid-a-brief-discussion-of-online-password-security where "The Weakest Link: Email Password Reset Mechanisms" is adressed, too.
While this thread is old I wanted to add my 2 cents. I think OpenId has one flaw that no one seems to care about. When I authenticate with Yahoo, it actually logs me into yahoo. It should not log you into yahoo it should just authenticate that you have the proper credentials with yahoo. When you log out of my app, you are still logged into yahoo. If you walk away from a shared computer and another person goes to yahoo, you will be logged in.. because when you authenticated with Yahoo, they also log you into their service. They should just authenticate you, not log you in. I have told several people about this and even demonstrated it with stackoverflow.com (who has a terrible log out mechanism, when I hit log out I expect to be logged out, not please click another logout button). Try this logout of yahoo or gmail. Close all your tabs, and then log into stackoverflow with yahoo/gmail. Then log out off stack overflow..(make sure you hit logout twice).. now browse to yahoo or gmail, you are logged in. Now the snide answer I get is "Don't use a shared computer, you should log out of Yahoo/gmail, etc"... Everyone is not a developer with a degree in MIS or computer science, my mother in law would think when she logged out of Stackoverflow, that she would not be logged into yahoo still.. Perhaps I am missing some parm or something that will actually force what I want, but it is surely not in the documentation telling you how great OpenId is!!!
Ouch. MyOpenID reports unconfirmed email addresses, just did a test for that. Looks like email info should be trusted only for some manually white-listed providers like google/yahoo and couple of others. I'll link the code here if someone's interested.
I like Verisign's VIP access which sites can make use of, and there is a nice little iPhone application that will let you have your generated token to get in, much like secureID