I am reading about oauth2 now, and trying to understand its purpose. From all the resouces I read, it seems like oauth2 is only used when a webapp (say a game app) that has some users and the app wants to access a user's Facebook or Google data (some sort of data such as name or email, etc). This part is clear to me. However, things that remain unclear to me are the following:
For example: If I have a webapp, and I want the users of my webapp to log into the webapp with their login and passwords (just like how you do it with gmail) without using any third party. Does oauth2 also serve this type of authorization?
I have seen webapps, where they just let users sign up with IDs and passwords, then they salt the passwords and store the salts in the database. So when a user logs in later, they salt the password the user entered, and compare this salt to the salt in the database (created during the signup). If equal, then the user logged in. This does NOT seem like oath at all to me. So if this is not oauth, what standard is this? And are there any other standards for "direct login" like this?
Assume that I want to allow users to sign up and log in to my website, but let them log in via a third party (like Facebook or Google). This is just for authorization purposes and assume that my app has no plan to post on their facebook or request their facebook data except that I may want to use their facebook email as the user ID for my webapp. Does oauth2 serve this type of authorization?
Sorry for the naive questions, because I only read about oauth recently.
For sign-up/login without 3rd-party, as Kevin pointed out, each programming/web framework usually comes with a popular library that once, it will generate all the sign-up/login pages, database tables, flow, etc., for you. The only thing you then do is call a method provided by the library that returns the current signed in user, in your backend code when you need to figure out who the user is.
Using salted password scheme is NOT related you OAuth2 at all as you pointed out. It is a widely used scheme for local authentication because it has many benefits but I will just highlight 2 here:
a. A password when transmitted from user to server for authentication over the Internet is not sent in cleartext but rather in hashed format. Thus even if it were eavesdropped, the password will not be divulged.
b. Since each password is salted, even 2 same passwords will not have the same hash because each have different salt. Thus even if a password hash was eavesdropped, it cannot be reused at another service that the user uses the same password because the other service expected a password hash generated with a different salt.
OAuth2 is all about Authorization (asking a user for permission to perform something on her behalf at another web service, e.g., ask a user for permission to access her email address registered on Facebook). Using it for Authentication can be insecure (for OAuth2 implicit flow). Why? The end result of OAuth2 is an access key associated with a permission, e.g., 'permission to access email address'. When you use the OAuth2 result (access key) for authentication, it means that you are making the assumption that 'permission to access email address' means the user successfully authenticated with Facebook, which she did, so it seems fine. However, imagine if another site also uses OAuth2 for authentication as you did; if it receives an access key with 'permission to access email address' it will assume that you have authenticated with Facebook so it will grant you access to the account belonging to the email address. You could actually use the access key you got from a user, and login as her in the other site, and vice versa.
To use OAuth2 for authentication, you need to use it with OpenID Connect (OIDC), because the end result of OAuth2-OIDC contains an id_token with the aud (audience) field identifying who the access key is for (https://openid.net/specs/openid-connect-core-1_0.html#IDToken), which prevents the access key from being reused where it is not intended. The full explanation with easy-to-understand diagrams is here: https://www.slideshare.net/KhorSoonHin/the-many-flavors-of-oauth/36?src=clipshare
Another very simple but perhaps unnerving to a security-conscious way to do use OAuth2 for login is to use the Resource Owner Password Credential, where your website acts as a middle-man between the user, and OAuth2 provider (Facebook).
Show 'Login with Facebook' button
When user clicks on button, prompt user for Facebook username/password
Use the username/password to login to Facebook to confirm authentication and get access token.
If you don't have to time to read in-depth about OAuth2, perhaps this side-by-side comparison of all the OAuth2 flow can help.
This is courtesy of https://blog.oauth.io/introduction-oauth2-flow-diagrams/
You could use OAuth for local logins like this, but you don't have to. It might be easier, depending on available libraries, and it might make sense if you anticipate making your service available to third-parties in the future. For many sites, though, using OAuth for local logins would be overkill.
Standards are most useful when different actors need to speak a common language so they can interoperate. For local logins you don't need a standard because you're not interacting with any third parties. Many web frameworks include their own variation on the same basic flow.
I think you're asking whether OAuth makes sense for authentication (establishing identity) when you don't actually need any authorization (permission to access third-party resources). It can indeed be used that way, but lots of people will warn against it since it wasn't designed for that and has some security weaknesses in that context. See, for example, Common pitfalls for authentication using OAuth.
I have been successfully able to run a Custom Login Page for Google Apps until today. I used to use Client for the Google Apps Provisioning service. using which we could send email (username) and password as parameters and obtain the authentication token.
With OAuth2 (as per Google we need to upgrade to OAuth2 starting 20th April, 2015) I can't find a solution! There's no way I can send/ check if a username/ password pair is correct.
There is no way now to do what you want. You could use SAML2 and then use Google as the source IDP via OpenID but you would end seeing the Google Login page again. It seems that you are trying to hide the fact that it is a Google shop.
SAML2 auth lets you design your own login screen but requires that you use your own user database.
Overview
Our SharePoint 2010 application will be launched from a 3rd party application, let's call it HealthApp, via an embedded URL. Much of the time the user will be logged into HealthApp from a shared workstation. As a result, SharePoint will not sign in automatically using the Active Directory credentials.
Requirements
We need single sign-on.
We need to continue to use Active Directory as the STS for various reasons.
Authentication from a stand-alone browser on the user's workstation will need to work as it does now.
Authentication Info
HealthApp can pass a username and any other custom identifier information we want as URL parameters.
The username will match the users Active Directory username.
We will not have a password.
We need some way to authenticate the user based only on the username/identifier.
Possible Solutions
Is there any way to bypass the password check in Active Directory?
This would appear to be the simplest solution if possible.
Can we
extend the Active Directory provider to authenticate using a generic
user and then log into SharePoint with the username passed on the
URL?
Any other suggestions?
I would think there would have to be some way to do this but have not had much experience with claims based authentication with SharePoint.
Thanks for any insight.
Me also facing same issue for authenticating users over share point site that uses claims authentication.As per requirements my app needs to access share point data. So to authenticate
over share point server from an app we need to provide some authenticated claims with the request so that share point STS can issue an authorization ticket to access the share point site resources. after spending more than 2 days in googling i found some interested article that may help to authenticate users from client app against identity provider systems.
OAuth library
this resides between app and identity provider system. using this you get an authenticated claims that will further use to authorize over share point server with the help of Share point STS.
We currently have a corporate portal in which users authenticate and get different page views based on their access level. We have been tasked with allowing them to click a Google Mail icon to sign them into their domain Google Mail Account. To do something like this, should we be looking in to oAuth or Open ID? Presently, they're already using their email and password to sign in.
From what we understand, Open ID requires their email and password to go to us, which we have; but will Open ID do what we're looking for?
Thank you.
Since your users have a Google Apps for Business email address already, I would suggest using the Google+ Federated Login feature-set. (You can learn more here: https://developers.google.com/accounts/docs/OpenID)
A quick snippet from the aforementioned link:
If you are planning to provide a “sign-in with Google” feature, we recommend using Google+ Sign-in, which provides the OAuth 2.0 authentication mechanism along with additional access to Google desktop and mobile features...[the] OpenID+OAuth Hybrid protocol lets web developers combine an OpenID request with an OAuth authentication request. This extension is useful for web developers who use both OpenID and OAuth, particularly in that it simplifies the process for users by requesting their approval once instead of twice.
You can find more on the Google+ Federated Login toolset and explore a sample application here: https://developers.google.com/+/
Hope this helps!
I would like to allow my users to choose from all the available authentication options that Azure Mobile Services provides when signing in but I'm not sure how to link their accounts together if say they choose to authenticate with Facebook the first time and then the next time they run the application they choose a different service.
You have to use a username that upon inserting to your table, you go through as to see if a username of this exists and then link it. Of course this could be a problem if another person wants to login with the same username.
The smartest thing is to retrive some information from the users account so you have some values you can see that are the same. And then you can link them inside.
You could look at this
Windows Azure Multi-Factor Authentication: http://www.windowsazure.com/en-us/documentation/services/multi-factor-authentication/