Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

What's a commonly accepted way of implementing SSO using a third party OAuth provider?

I have a server with user resources associated with server's user ID, the user ID also has a Facebook user ID associated. Would it be a good approach to authenticate a client to the server if the login was redirected to, say, Facebook where it would return an OAuth token and the token is then shared with the client?

Suppose SSL is implemented, the OAuth token would then act in the same way as a session cookie that gives permission to user resources on the server.

The same user an different client can then reauthenticate with Facebook which would return the same Facebook ID, which gives access to the same user's resources and a different OAuth token which expires independently and removing the app on Facebook can callback the server with a deauthenticate request to keep things synchronised.

Is this a good policy to use? Is it safe against attacks like session sidejacking, cross site reference etc?

share|improve this question

1 Answer 1

I think you are getting a little confused there.

SSO comes into question when there are two or more apps involved(ex: gmail, google drive and google plus are three different apps that have SSO, you sign in into one of them, the others will have signed in automatically). Are there two applications in this question?

You don't share the oAuth access token with the client. By client, I believe you mean the browser anyway. You keep the oAuth access token in the server tied to the user session or persist in the database. The oAuth access token will expire after some time(exact time is specified in the response). When the access token expires, you get a new access token with the refresh token that you saved when the user first authorized your application at the provider. You have to keep the refresh token forever by persisting in the database. By any means, if you lose the refresh token, you should have the user sign-in into the oAuth provider site and get the authorization done again so you'll get the refresh token.

share|improve this answer
    
You're right, I should have clarified. I meant client as a desktop/mobile application. As a browser, the session cookie can acts a bridge between the browser and the user/OAuth on the server side but without a browser, is it common practice to use the OAuth token as is instead of recreating a session cookie logic in the application? –  Xster Jan 18 '13 at 16:47
    
I see no harm in doing so. Even if the some one gets hold of the access token, they still need the client id and client secret to make any requests to the provider. If you are making the requests to the provider always from the client, you will definitely need all client id, client secret and access token present in your client. In that case, you should use SSL for your client/server communication. I hope I'm clear. –  Sundeep Jan 19 '13 at 8:10

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.