SAML vs federated login with OAuth

What's the difference between SAML and federated login with OAuth? Which solution makes more sense, if a company wants to use a third-party webapp, and but also wants single sign-on and be the authentication authority?

Is there a Node OAuth Server Implementation [closed]

I only found the oauth client library for nodejs. Does anybody know where I can find a server implementation?

Thanks,
Hao.

Authenticating with OAuth2 for an app *and* a website

I'm developing a website that is primarily accessed via an app, and I want to use OAuth2 for user registration and authentication. Since it is an Android app I will start using Google's OAuth2 stuff, since it provides a decent UI on Android.

Google states that "You can choose to use Google's authentication system as a way to outsource user authentication for your application. This can remove the need to create, maintain, and secure a username and password store." which is what I want to do. However when I go through all their examples and whatnot, I can only find stuff about having a website or an app authenticate a user against Google's services.

And indeed, when I go to register my app ("client") with Google's OAuth2 there are options for website clients and "installed" clients (i.e. a mobile app) but not both. I can create two separate clients but I read the OAuth2 draft and I think there will be a problem, which I will now explain.

Here's how I did envisage it working:

1. User asks MyApp to access his private data.
2. App uses Android's AccountManager class to request an access token for Google's APIs.
3. Android says to user "The app 'MyApp' wants access to your Basic Information on Google. Is this ok?"
4. User says yes.
5. AccountManager connects to Google's OAuth2 server using the credentials stored on the phone, and asks for an access token.
6. Access token (which follows the green lines) is returned.
7. AccountManager returns the access token to MyApp.
8. MyApp sends a request to MySite for the user's private data, including the access token.
9. MySite needs to verify the user, using the access token. It validates the token as described here, with Google - "Google, is this token valid?".
10. Now, what I want to happen is that Google says "Yes, whoever gave it to you is indeed that user.", but what I think will actually happen (based on the OAuth2 draft and Google's documentation) is that it will say "No way! That token is only valid for MyApp, and you're MySite. GTFO!".

So how should I do this? And PLEASE don't say "Use OpenID" or "Don't use OAuth2" or other similarly unhelpful answers. Oh and I would really like to keep using the nice AccountManager UI rather than crappy popup WebViews

Edit

Provisional answer (I will report back if it works!) from Nikolay is that it should actually work, and Google's servers won't care where the access token came from. Seems a bit insecure to me, but I will see if it works!

Update

I implemented this pattern with Facebook instead of Google and it totally works. The OAuth2 server doesn't care where the access token comes from. At least Facebook's doesn't, so I assume Google's doesn't either.

In light of that it is a very very bad idea to store access tokens! But we also don't want to have to hit Facebook/Google's servers to check authentication for every request since it will slow everything down. Probably the best thing is to add an additional authentication cookie for your site that you hand out when their access token is validated, but a simpler way is just to treat the access token like a password and store a hash of it. You don't need to salt it either since access tokens are really really long. So the steps above become something like:

9. MySite needs to verify the user, using the access token. First it checks its cache of hashed valid access tokens. If the hash of the token is found there it knows the user is authenticated. Otherwise it checks with Google as described here, with Google - "Google, is this token valid?".

10. If Google says the access token is invalid, we tell the user to GTFO. Otherwise Google says "Yes that is a valid user" and we then check our registered user database. If that Google username (or Facebook id if using Facebook) is not found we can create a new user. Then we cache the hashed value of the access token.

Facebook Oauth Logout

I have an application that integrates with Facebook using Oauth 2.

I can authorize with FB and query their REST and Graph APIs perfectly well, but when I authorize an active browser session is created with FB. I can then log-out of my application just fine, but the session with FB persists, so if anyone else uses the browser they will see the previous users FB account (unless the previous user manually logs out of FB also).

The steps I take to authorize are:

1. Call [LINK: graph.facebook.com/oauth/authorize?client_id...]

This step opens a Facebook login/connect window if the user's browser doesn't already have an active FB session. Once they log-in to facebook they redirect to my site with a code I can exchange for an oauth token.

1. Call [LINK: graph.facebook.com/oauth/access_token?client_id..] with the code from (1)

Now I have an Oauth Token, and the user's browser is logged into my site, and into FB.

1. I call a bunch of APIs to do stuff: i.e. [LINK: graph.facebook.com/me?access_token=..]

Lets say my user wants to log out of my site. The FB terms and conditions demand that I perform Single Sign Off, so when the user logs out of my site, they also are logged out of Facebook. There are arguments that this is a bit daft, but I'm happy to comply if there is any way of actually achieving that.

I have seen suggestions that:

A. I use the Javascript API to logout: FB.Connect.logout(). Well I tried using that, but it didn't work, and I'm not sure exactly how it could, as I don't use the Javascript API in any way on my site. The session isn't maintained or created by the Javascript API so I'm not sure how it's supposed to expire it either.

B. Use [LINK: facebook.com/logout.php]. This was suggested by an admin in the Facebook forums some time ago. The example given related to the old way of getting FB sessions (non-oauth) so I don't think I can apply it in my case.

C. Use the old REST api expireSession or revokeAuthorization. I tried both of these and while they do expire the Oauth token they don't invalidate the session that the browser is currently using so it has no effect, the user is not logged out of Facebook.

I'm really at a bit of a loose end, the Facebook documentation is patchy, ambiguous and pretty poor. The support on the forums is non-existant, at the moment I can't even log in to the facebook forum, and aside from that, their own FB Connect integration doesn't even work on the forum itself. Doesn't inspire much confidence.

Ta for any help you can offer. Derek

ps. Had to change HTTPS to LINK, not enough karma to post links which is probably fair enough.

Facebook Access Token for Pages

I have a Facebook Page that I want to get some things from it. First thing are feeds and from what I read they are public (no need for access_token). But I want to also get the events... and they aren't public and need the access_token.

I don't want the user to login in Facebook or anything like that. I just want to push all the data I can from this only page. That's why I already discarded many examples I found here and the one at https://developers.facebook.com/blog/post/500/ , because they want the user to login or require some user action I'm not interessed.

What I want is that my Facebook Application have full authorization and access_token to push the data from this one Facebook Page that I own (admin). Is this possible? I already tried many things but nothing seems to work.

I tried clicking at this: https://www.facebook.com/dialog/oauth?client_id=150635421702954&redirect_uri=http://MY_URL/&scope=manage_pages&response_type=token&fields=access_token - changing MY_URL to my site's and it requests authorization to edit every page I own. Even not being what I want I clicked but had no access_token in return...

Could someone please help me?

Greatly appreciated, thank you :)

OAuth with Verification in .NET

I'm trying to create a .NET-based client app (in WPF - although for the time being I'm just doing it as a console app) to integrate with an OAuth-enabled application, specifically Mendeley (http://dev.mendeley.com), which apparently uses 3-legged OAuth.

This is my first time using OAuth, and I'm having a lot of difficulty getting started with it. I've found several .NET OAuth libraries or helpers, but they seem to be more complicated than I think I need. All I want to do is be able to issue REST requests to the Mendeley API and get responses back!

So far, I've tried:

• DotNetOpenAuth
• http://github.com/bittercoder/DevDefined.OAuth
• http://oauth.googlecode.com/svn/code/csharp/

The first (DotNetOpenAuth) seems like it could possibly do what I needed if I spent hours and hours trying to work out how. The second and third, as best I can tell, don't support the verification codes that Mendeley is sending back -- although I could be wrong about this :)

I've got a consumer key and secret from Mendeley, and with DotNetOpenAuth I managed to get a browser launched with the Mendeley page providing a verification code for the user to enter into the application. However, at this point I got lost and couldn't work out how to sensibly provide that back to the application.

I'm very willing to admit that I have no idea where to start with this (although it seems like there's quite a steep learning curve) - if anyone can point me in the right direction I'd appreciate it!

How to keep the OAuth consumer secret safe, and how to react when it's compromised?

This question is about trying to understand the security risks involved in implementing oauth on a mobile platform like Android. Assumption here is that we have an Android application that has the consumer key/secret embedded in the code.

Assuming a consumer secret has been compromised, and a hacker has gotten a hold of it, what are the consequences of this ?

Compromised Consumer Secret assumptions
Am I correct in stating that a compromised consumer secret as such has no effect on the user's security, or any data stored at the OAuth enabled provider that the user was interacting with. The data itself is not compromised and cannot be retrieved by the hacker.

The hacker would need to get a hold of a valid user access token, and that's a lot harder to get.

What could a hacker do with a compromised consumer secret ?
Am I also correct in stating the following :

• The hacker can setup/publish an application that imitates my app.
• The hacker can attract users that will go through the OAuth flow, retrieving an access token via the hackers OAuth dance (using the compromised consumer key/secret).
• The user might think he's dealing with my app, as he will see a familiar name (consumer key) during the authorization process.
• When a consumer issues a request via the hacker, the hacker can easily intercept the access token, and combined with the consumer secret can now sign requests on my behalf to gain access to my resources.

End-user impact
In the assumption that

• a hacker has setup an application / site using my consumer secret
• one of my users was tricked into authorizing access to that application / site

The following might happen :

• the end-user may being noticing that something fishy is going on, and inform the service provider (ex: Google) about the malicious app
• the service provider can then revoke the consumer key/secret

OAuth consumer (my application) impact :
My app (containing the consumer secret) would need to be updated, as otherwise all my clients would not be able to authorize my application do to requests on their behalf anymore (as my consumer secret would no longer be valid).

Delegating all OAuth traffic
Although it would be possible to delegate a lot of the OAuth interactions via an intermediate webserver (doing the OAuth dance and sending the access token to the user), one would have to proxy all service interactions also, as the consumer key/secret is required for signing each request. Is this the only way to keep the consumer key/secret outside of the mobile app, and stored in a more secure place on the intermediate webserver ?

Alternatives
Are there alternatives for this proxy-ing ? Is it possible to store the consumer secret at the intermediate webserver, and have some kind of mechanism that the Android application (published in the market and properly signed), can do a secure request to the intermediate webserver to fetch the consumer secret and store it internally in the app ? Can a mechanism be implemented that the intermediate webserver "knows" that this is an official android app that is requesting to fetch the consumer secret, and that the intermediate webserver will only handout the consumer secret to that particular android app ?

Best practices around generating OAuth tokens?

I realize that the OAuth spec doesn't specify anything about the origin of the ConsumerKey, ConsumerSecret, AccessToken, RequestToken, TokenSecret, or Verifier code, but I'm curious if there are any best practices for creating significantly secure tokens (especially Token/Secret combinations).

As I see it, there are a few approaches to creating the tokens:

1. Just use random bytes, store in DB associated to consumer/user
2. Hash some user/consumer-specific data, store in DB associated to consumer/user
3. Encrypt user/consumer-specific data

Advantages to (1) is the database is the only source of the information which seems the most secure. It would be harder to run an attack against than (2) or (3).

Hashing real data (2) would allow re-generating the token from presumably already known data. Might not really provide any advantages to (1) since would need to store/lookup anyway. More CPU intensive than (1).

Encrypting real data (3) would allow decrypting to know information. This would require less storage & potentially fewer lookups than (1) & (2), but potentially less secure as well.

Are there any other approaches / advantages / disadvantages that should be considered?

EDIT: another consideration is that there MUST be some sort of random value in the Tokens as there must exist the ability to expire and reissue new tokens so it must not be only comprised of real data.

Follow On Questions:

Is there a minimum Token length to make significantly cryptographically secure? As I understand it, longer Token Secrets would create more secure signatures. Is this understanding correct?

Are there advantages to using a particular encoding over another from a hashing perspective? For instance, I see a lot of APIs using hex encodings (e.g. GUID strings). In the OAuth signing algorithm the Token is used as a string. With a hex string, the available character set would be much smaller (more predictable) than say with a Base64 encoding. It seems to me that for two strings of equal length, the one with the larger character set would have a better/wider hash distribution. This seems to me that it would would improve the security. Is this assumption correct?

The OAuth spec raises this very issue in 11.10 Entropy of Secrets.

What is the purpose of the implicit grant authorization type in OAuth 2?

I don't know if I just have some kind of blind spot or what, but I've read the OAuth 2 spec many times over and perused the mailing list archives, and I have yet to find a good explanation of why the Implicit Grant flow for obtaining access tokens has been developed. Compared to the Authorization Code Grant, it seems to just give up on client authentication for no very compelling reason. How is this "optimized for clients implemented in a browser using a scripting language" (to quote the specification)?

Both flows start out the same (source: http://tools.ietf.org/html/draft-ietf-oauth-v2-22):

1. The client initiates the flow by directing the resource owner's user-agent to the authorization endpoint.
2. The authorization server authenticates the resource owner (via the user-agent) and establishes whether the resource owner grants or denies the client's access request.
3. Assuming the resource owner grants access, the authorization server redirects the user-agent back to the client using the redirection URI provided earlier (in the request or during client registration).
   • The redirection URI includes an authorization code (Authorization code flow)
   • The redirection URI includes the access token in the URI fragment (Implicit flow)

Here's where the flows split. In both cases the redirection URI at this point is to some endpoint hosted by the client:

• In the Authorization code flow, when the user agent hits that endpoint with the Authorization code in the URI, code at that endpoint exchanges the authorization code along with its client credentials for an access token which it can then use as needed. It could, for example, write it into a web page that a script on the page could access.
• The Implicit flow skips this client authentication step altogether and just loads up a web page with client script. There's a cute trick here with the URL fragment that keeps the access token from being passed around too much, but the end result is essentially the same: the client-hosted site serves up a page with some script in it that can grab the access token.
  

Hence my question: what has been gained here by skipping the client authentication step?

OAuth2 - Why do access tokens expire?

I am just getting started working with googles API and Oauth2. When the client authorizes my app I am given a "refresh token" and a short lived "access token". Now every time the access token expires, I can POST my refresh token to google and they will give me a new access token.

My question is what is the purpose of the access token expiring? Why cant there just be a long lasting access token instead of the refresh token?

Also, does the refresh token expire?

For more info on Google Oauth2 workflow - http://code.google.com/apis/accounts/docs/OAuth2.html

I appreciate any thoughts on this.

Thanks

OAuth secrets in mobile apps

When using the OAuth protocol, you need a secret string obtained from the service you want to delegate to. If you are doing this in a web app, you can simply store the secret in your data base or on the file system, but what is the best way to handle it in a mobile app (or a desktop app for that matter)?

Storing the string in the app is obviously not good, as someone could easily find it and abuse it.

Another approach would be to store it on your server, and have the app fetch it on every run, never storing it on the phone. This is almost as bad, because you have to include the URL in the app.

The only workable solution I can come up with is to first obtain the Access Token as normal (preferably using a web view inside the app), and then route all further communication through our server, which would append the secret to the request data and communicate with the provider. Then again, I'm a security noob, so I'd really like to hear some knowledgeable peoples' opinions on this. It doesn't seem to me that most apps are going to these lengths to guarantee security (for example, Facebook Connect seems to assume that you put the secret into a string right in your app).

Another thing: I don't believe the secret is involved in initially requesting the Access Token, so that could be done without involving our own server. Am I correct?

Securing my REST API with OAuth while still allowing authentication via third party OAuth providers (using DotNetOpenAuth)

I have a product with a straightforward REST API so that users of the product can directly integrate with the product's features without using my web user interface.

Recently I have been getting interest from various third parties about integrating their desktop clients with the API to allow users of my product to access their data using that third party application.

I've seen that applications that want to use Twitter authenticate using a login page hosted by Twitter that grants a specific application permission to access that user's data. You click the "Allow" or "Deny" button and the authentication process is complete. Facebook uses the same mechanism as best I can tell.

Upon further research, this seems to be OAuth in action, and seeing as my API is .Net-based, I am thinking I should use DotNetOpenAuth and provide a similar mechanism. Unfortunately the samples are sparsely documented (if at all) and the only tutorials I can find online seem to be focussed on helping you provide a login mechanism for your users so that they can log into your website using a third party provider.

What I would really like to do is have my REST API handle all of the core authentication and business logic for my web application and have, under the hood, my web application essentially be another application that just uses the API via OAuth. Users would authenticate on the website either directly using their username and password, or via a third party provider such as MyOpenID or Facebook and then the website would somehow use the returned token to authenticate against the REST API.

It basically looks like I need my API to somehow host an OAuth service, but also have users use a third party OAuth service. I can't help but think I don't quite have enough of a grasp on OAuth to decide if I'm overcomplicating things or if what I'm trying to do is a good or bad way to do things.

Can someone give me at least a broad overview of the steps I need to undertake, or what I should look at to make this happen? Or point me at some tutorials? Or blast my proposal and tell me I'm going about this (architecturally) all wrong?

SSO with CAS or OAuth?

I wonder if I should use the CAS protocol or OAuth + some authentication provider for single sign-on.

Example Scenario:

1. A User tries to access a protected resource, but is not authenticated.
2. The application redirects the user to the SSO server.
3. If beeing authenticated the user gets a token from the SSO server.
4. The SSO redirects to the original application.
5. The original application checks the token against the SSO server.
6. If the token is ok, access will be allowed and the application knows of the user id.
7. 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.

Architecture for merging multiple user accounts together

Okay, I got a website where you can register yourself and login. You can also login with your facebook, twitter or linkedin account.

It is important that users only have one account registered. So somehow, I want to merge the accounts of users if they use different methods to login. What is the best solution to solve this?

For instance, the user logs in with his Facebook account. I use the data to register an account for him automatically. Should I sent an e-mail with an username and password of our website? (If this is okay with the policy of Facebook). Should I give them a second screen where they can fill in an username and password? But that's not the idea behind logging in with your Facebook account. It should simplify your procedure to participate.

It's also possible the user has registered himself on our website and the next time he logs in with his twitter account. How can I merge these 2 accounts as one? What's the best way?

So basically my question is: I got 4 different ways a user becomes a member of our website. How can I make sure all these 4 ways only create one account if a user decides to use multiple ways? What's the best flow to make sure that it doesn't become a hassle for the user himself?

Edit:

3 years after I asked this question, I am giving the answer myself in a series of articles: http://www.sitepoint.com/series/using-social-networks-as-a-login-system/

OAuth 2.0: Benefits and use cases — why?

Could anyone explain what's good about OAuth2 and why we should implement it? I ask because I'm a bit confused about it — here's my current thoughts:

OAuth1 (more precisely HMAC) requests seem logical, easy to understand, easy to develop and really, really secure.

OAuth2, instead, brings authorization requests, access tokens and refresh tokens, and you have to make 3 requests at the very start of a session to get the data you're after. And even then, one of your requests will eventually end up failing when the token expires.

And to get another access token, you use a refresh token that was passed at the same time as the access token. Does that make the access token futile from a security point of view?

Plus, as /r/netsec have showed recently, SSL isn't all entirely secure, so the push to get everything onto TLS/SSL instead of a secure HMAC confuses me.

OAuth are arguing that it's not about 100% safety, but getting it published and finished. That doesn't exactly sound promising from a provider's point of view. I can see what the draft is trying to achieve when it mentions the 6 different flows, but it's just not fitting together in my head.

I think it might be more my struggling to understand it's benefits and reasoning than actually disliking it, so this may be a bit of an unwarranted attack, and sorry if this could seem like a rant.