I am running an ecommerce website and would like to make the website more accessible, hence I am thinking of using OAuth so they can login using some of their social media profiles. I also send out a lot of marketing campaigns to my customers via email and other methods, so at the moment when a user signs up I have some information such as their email and some details about their occupation (relevant to the products, don't worry I am not being nosy!).
If a user signs in using OAuth, then they won't be providing me with some of this basic information such as their email, as they don't have to use a signup form.
So, when implementing OAuth, I want to know what data I can store to my database about the user? At the moment I can send a newsletter to all of the users on my website for example, but with OAuth is something like this possible? What kind of information can I access for each user if they are signed in using OAuth?
Sorry if these questions have been answered elsewhere, I have been trying to search around but haven't found anything about what the company can gain, I've only found the advantages and disadvantages from a basic coding point of view and from a user point of view.
Thanks!
Using OpenID Connect, which is a standardized extension profile of OAuth 2.0 you can authenticate users through 3rd party providers. There are also a number of providers out there that have created their own proprietary extensions of OAuth 2.0 that gives them login semantics, but they are not standardized and your client code would have to deal with each of these proprietary extensions. It can be expected that all providers using proprietary OAuth 2.0 extensions for login migrate to OpenID Connect in the future.
OpenID Connect (and also the proprietary OAuth 2.0 extension protocols) do not just authenticate users but they also provide user identity information in the form of claims (or: attributes). So they do provide the basic information that you are looking for (e.g. e-mail) if only the user consents to giving it to your client. You can use that information and store it in your database for offline access.
The benefit of OpenID Connect is that it has standardized a number of basic claims so that your code can be provider agnostic when dealing with user info. See http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims. The proprietary OAuth 2.0 login protocols do not provide standardized claims so you need custom handling (mapping/translation) per provider.
Related
I'm trying to secure an API with modern security practices (like refresh tokens with token rotation).
OAuth 2.0 is widely used, and when it comes to security I'd rather use a standard than role my own.
Is there are standard like OAuth 2.0, but for applications which do not have 3rd party consumers?
In our case, we're authenticating users via various SSO providers (Google, Facebook, etc) and registering their email with our API.
Currently we issue a token on each login with a long TTL, but I'd like to switch to a refresh token implementation.
A similar question was asked where the suggestion was to use OAuth as-is and treat the users as coming from a single application: using oauth for API without 3rd party
However, wouldn't the user have to authenticate our app to use our app? That seems counter-intuitive, so I assume I'm missing something.
Also, I'm implementing this in Spring.
Thank You!
I'm not sure about what you mean by "not 3rd party application". Have you considered using an (OpenID) authorization-server with user identity federation features?
Such an authorization-server would be a proxy for the various identity providers: "social" ones (Google, Facebook, etc.) but also corporate ones, if needed (LDAP or plain user DB). Keycloak, for instance does that pretty well and can be easily installed along with your other services ("in house").
UI applications would be configured as regular OpenID clients, using your authorization-server as only identity (and access-tokens) provider. There are great client libs out there to handle that in the framework you use (mobile, Angular, React, etc.)
redirects out to the authorization-server and then back in
tokens refreshing
URIs for which an Authorization header should be attached to the requests
...
Spring applications exposing the API would be configured as regular OAuth2 resource-servers, using your authorization-server as only access-token issuer.
Let's say we have a backend in ExpressJS. We are using simple BcryptJS to hash and store passwords and emails in the database.
Now I want to add the link social media accounts feature like this:
Now what I was wondering is what should I store in the database? Like lets say I registered using email and password, now I go in settings and add Google login, what should I store with the user's record in the database to use the Google identity in the future when needed? Like should I store the access token? the refresh token? Should I keep refreshing the token? Should I not even store the token?
Sorry if it might sound silly, but I googled around and didn't find the answer I wanted, and I have spent the last hour thinking about this. What do you guys think? And this answer might help a lost developer in the future too.
SOCIAL LOGINS
If this is your starting point, and assuming that the email used from Google or Facebook matches that used when logging in with passwords:
Field
Example Value
User ID
203
Email
john#company.com
Then when you receive the Google or Facebook response you would need to look for an email in it, either by inspecting the ID token or calling their user info endpoint. You can then match to the User ID that makes sense to your business data.
If you store anything from those providers it should be a linked record, something like this. You should only need to store access tokens from the third party provider if your app needs to access the user's Google or Facebook resources with it:
Field
Example Value
User Link ID
1039
User ID
203
Provider
Google
Subject
d2ee68ee-7853-11ec-90d6-0242ac120003
PROBLEM AREAS
The above mechanism is inherently unreliable and can easily result in duplicate users in your business data, eg if the social provider does not give you an email and the user exists already in your business data. A technique to solve this problem can be to involve the user - ask them if they exist already in your app and if so then ask them to authenticate with an existing method (password in your case) as part of onboarding to social logins.
Foreign access tokens, from Google and Facebook, are not designed to be used to secure your own APIs - you may not even be able to validate them in some cases, and you will not be able to control claims and scopes. This leads some people to write custom code to issue their own tokens.
AUTHORIZATION SERVER
For future reference, the preferred architecture is for your UIs and APIs to only talk to your own Authorization Server, which is hosted alongside APIs. This component will then manage the following aspects for you, all of which will keep the security plumbing out of your apps:
Login connections to social providers
Dealing with provider specific differences
Providing account linking capabilities
Storing linked records
Allowing you to return your own customized tokens to your own apps
In more advanced use cases the AS can also hold onto the third party access token for you via the embedded token approach.
Our current system is pure ASP.net web application. We got our own login page, where user will enter his username and password for authentication and authorisation. System will verify this from our user table and if it is matched, it will create a security session object for the user which will be verified on each page. We got our own user_profile table for authorization on each module/functionality.
We are re-designing our system using Web Api with AJAX and to support Mobile. On successful login new token should be created for the user either using IdentityServer or Authorisation Server, so he could use that token for each webapi call.
For our system when it comes to the security, we got no experience in this area. After some googling understood the OAuth.
Also found that so many people referring Thinktecture for security implementations. based on some googling on Thinktecture my understanding is
IdentityServer - which will be used for authentication
AuthorizationServer - which will be issued tokens based on user's access. This AuthorizationServer got its own pages to create users, roles and DB to store these details.
In our case since we got our own user table and user profile mappings for the modules, we believe that we dont need these admin module to create user/role and DB from authorizationserver.
Can some anyone guide us where exactly these servers fit in our requirement? Which one do you recomment for our scenario?
Apologies, if these questions has been asked earlier and it has been answered.
Right now IdentityServer is in a transition. IdentityServer v2 is more for authentication (and has some OAuth2 support, mainly for authentication). AuthorizationServer is more forcused on OAuth2 for delegated authorization. Many people have been confused in the past about which one they wanted/needed, so for IdentityServer v3 we've combined the two, but right now (June 2014) we're still in preview for IdentityServer v3. We plan a beta of IdentityServer v3 for end of summer and release by the fall.
Lets stick with Facebook for this example.
I am asuming that FB uses it's own public API's (as well as internal ones, that only they can use), and as they are using OAuth 2, would it be safe to assume they have "special client registrations" with permission to use the Resource Owner Password Credential Grant?
As you may know, when logging into Facebook from their own official apps, they don't pop open a browser, asking you if you allow Facebook to use Facebook, so if they are using OAuth themselves, how are they doing this securely?
We've all read that Twitter got their consumer keys leaked, how are Facebook avoiding this?
I am no security expert, nor do I have experience in reverse engineering, I am just in a situation where I am to implement an OAuth authorization server myself, and we wish to expose our API's to 3rd parties, but as we ourselves have "official native apps", we'd like to use the Resource Owner Password Credential grant, for the best user experience.
As per the OAuth 2 spec, native apps should not include client secrets, but how does that make things better? The way I see it, if you don't include the secret, and your client ID is extracted and used for password grants, the only way you can revoke it is by completely removing the client ID from your authorization server.
Am I missing something obvious here? How do "the big guys" do this?
The big difference is, that the official Facebook app knows your username and password and therefore don't need to pop a browser, because they can directly authenticate.
As a third party app, I cannot (ok, I could, but for privacy reasons I won't) ask for the users email and password. As official app, you can do this and thus directly perform a login (this may happen through an undocumented REST endpoint)
I wonder if I should use the CAS protocol or OAuth + some authentication provider for single sign-on.
Example Scenario:
A User tries to access a protected resource, but is not authenticated.
The application redirects the user to the SSO server.
If beeing authenticated the user gets a token from the SSO server.
The SSO redirects to the original application.
The original application checks the token against the SSO server.
If the token is ok, access will be allowed and the application knows of the user id.
The user performs a log-out and is logged out from all connected application at the same time (single sign-out).
As far as I understand that is exactly what was CAS invented for. CAS clients have to implement the CAS protocol to use the authentication service. Now I'm wondering about to use CAS or OAuth at the client (consumer) site. Is OAuth a replacement for that part of CAS? Should OAuth as a new de-facto standard be preferred? Is there an easy to use (not Sun OpenSSO!) replacement for the authentication part of CAS supporting different methods like username/password, OpenID, TLS certifactes ...?
Context:
Different applications should rely on the authentication of the SSO server and should use something session-like.
The applications can be GUI web applications or (REST) serivces.
The SSO server must be provide a user id, which is necessary to get more information about the user like roles, email and so on from a central user information store.
Single Sign-out should be possible.
Most clients are written in Java or PHP.
I've just discovered WRAP, which could become the OAuth successor. It is a new protocol specified by Microsoft, Google and Yahoo.
Addendum
I've learned that OAuth was not designed for authentication even it could be used to implement SSO, but only together with a SSO service like OpenID.
OpenID seems to me to be the "new CAS". CAS has some features OpenID misses (like single sign-out), but it should not be to hard to add the missing parts in a particular scenario. I think OpenID has broad acceptance and it is better to integrate OpenID into applications or application servers. I know that CAS also supports OpenID, but I think CAS is dispensable with OpenID.
OpenID is not a 'successor' or 'substitute' for CAS, they're different, in intent and in implementation.
CAS centralizes authentication. Use it if you want all your (probably internal) applications to ask users to login to a single server (all applications are configured to point to a single CAS server).
OpenID decentralizes authentication. Use it if you want your application to accept users login to whatever authentication service they want (the user provides the OpenID server address - in fact, the 'username' is the server's URL).
None of the above handle authorization (without extensions and/or customization).
OAuth handles authorization, but it is not a substitute for the traditional 'USER_ROLES table' (user access). It handles authorization for third-parties.
For example, you want your application to integrate with Twitter: a user could allow it to tweet automatically when they update their data or post new content. You want to access some third-party service or resource on behalf of a user, without getting his password (which is obviously unsecure for the user). The application asks Twitter for access, the user authorizes it (through Twitter), and then the app may have access.
So, OAuth is not about Single Sign-On (nor a substitute for the CAS protocol). It is not about you controlling what the user can access. It is about letting the user to control how their resources may be accessed by third-parties. Two very different use-cases.
To the context you described, CAS is probably the right choice.
[updated]
That said, you can implement SSO with OAuth, if you consider the identity of the user as a secured resource. This is what 'Sign up with GitHub' and the likes do, basically. Probably not the original intent of the protocol, but it can be done. If you control the OAuth server, and restrict the apps to only authenticate with it, that's SSO.
No standard way to force logout, though (CAS has this feature).
I tend to think of it this way:
Use CAS if you control/own the user authentication system and need to support a heterogenous set of servers and apps that need centralized authentication.
Use OAuth if you want to support user authentication from systems that you don't own/support (ie Google, Facebook, etc).
OpenID is an authentication protocol, OAuth and OAuth WRAP are authorization protocols. They can be combined with the hybrid OpenID extension.
I'd strongly prefer to see people building on top of standards that have a lot of momentum (more available support, easier to get third parties involved), even if they aren't an exact fit for the application at hand. In this case, OAuth has the momentum, not CAS. You ought to be able to do all or at least nearly all of what you need to do with OAuth. At some later point in the future, OAuth WRAP should simplify things further (it makes some worthwhile trade-offs by using a bearer token and pushing encryption down to the protocol layer), but it's still in its infancy, and in the meantime, OAuth will probably do the job just fine.
Ultimately, if you choose to use OpenID and OAuth, there are more libraries for more languages available to you and to anyone else who needs to integrate with the system. You also have a lot more eyeballs looking at the protocols, making sure they really are as secure as they're supposed to be.
To me, the real difference between SSO and OAuth is grant, not authentication
because a server that implements OAuth obviously has authentication (you have to be logged in to your google, openId or facebook for OAuth to happen with the client app)
In SSO, a power user/sysadmin grants the final user access to an application beforehand on the "SSO app"
In OAuth, final user grants application access to his "data" on the "OAuth app"
I don't see why OAuth protocol couldn't be used as part of an SSO server. Just take out the grant screen from the flow and let the OAuth server lookup the grant from the backing db.
Old post, but this might be useful:
CAS 3.5 will support oAuth as Client and Server.
See: https://wiki.jasig.org/display/CASUM/OAuth