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?
Best Answer
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.