Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<blockquote> <p>Why can't I just rely purely on OAuth?</p> </blockquote> <p>From a service providers perspective, OAuth is a means of controlling access of third party applications to the business logic. The end user does not have to give out his password to the third party app, and the access can be controlled. For example, the provider could restrict the access to only parts of the service for limited amount of time.</p> <p>If you write a third party application, there is no strict need for you to have your "own" user artifacts. You can rely on the users that authenticate your application. </p> <p>You could require that user's have an account with a provider such as Facebook or Twitter and not implement any password stuff yourself. </p> <p>(You probably need some sort of artifact to represent a user, it should in this case contain information about how that user authenticates your application, for instance an OAuth token, or an OpenID URL).</p> <blockquote> <p>If I do, do I need hash / salt anything if I save it? I don't store any passwords, but what about tokens?</p> </blockquote> <p>Just to clarify, in OAuth a token is typically both a key and a secret, and they are needed in cleartext to sign requests (there are differences here depending on which version of OAuth you use). So you can store them encrypted, as long as it is reversible for you.</p> <blockquote> <p>I still need to persist the users so they won't login everytime, (like in OS) - do I somehow use the OAuth token (save it? does it make even sense)?</p> </blockquote> <p>Yes this makes sense, a token represents your applications access to a specific user's data. Save the token if you want to keep a "session" alive.</p> <blockquote> <p>How do I implement logging out? I can't force them to log out of the OAuth provider, and if I only delete the httpOnly cookie / invalidate their session locally, is that enough? and security issues?</p> </blockquote> <p>There is no concept of "logging" out of OAUth, a token either has an expiration time or not. You can of course "log out" by simply choosing to forget the token. The next time you will have to redo the authentication. You cannot force users to invalidate an access token, unless the provider has an API for that.</p> <p>You could save the token in a cookie, but I would use other unique identifiers for the session you want to keep alive. You can persist the details of the tokens server side. The information you store in your cookie shold make it possible to retrieve the token you need. </p> <blockquote> <p>How do I implement single sign on? I don't want the user, after approving to click again "log in using Facebook / Twitter / Google" I want an effect similiar to SO (page refreshes and "welcomes you back" what are the best practices to do that? Why does SO refreshes the page (I assume it has to do with the fact it needs to be client side, but I don't fully understand how it works to even know what to ask)</p> </blockquote> <p>If you save a token in a database, save an ID for that token in a nice secure cookie. When a user goes to your service, use the information in the cookie to make a call from your service, to the service provider, to check if the token is still valid. If so, you have established enough trust for you to "log in" the user in your application without having to go through the pain of the OAuth process again.</p> <p>And as a side not, StackOverflow uses OpenID and not OAuth for user authentication. OAuth can be used for the same purpose but is mainly a specification for application authorization.</p> <p>I hope this helped, and don't sell yourself short. This site is for posting questions, not for appearing all-knowing.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload