2

Given a setup where user credentials are stored on a server, but web services will be called from third-party clients, does the following seem reasonable:

  1. When clients want to login, they send username/password to server (over ssl, confirmed against salted scrypt hash stored in server db)

  2. Server checks credentials and upon validation creates JWT tokens which contain the user id and signs it with the private side of RSA public/private keypair. (more specifically, uses AppEngine's methods for signing- https://github.com/someone1/gcp-jwt-go/blob/master/appengine.go)

  3. Clients use the public key and verify that the signature is correct. From that point forward they consider the user logged in. Note that the public key can be bundled with the client, or requested from the server and cached.

  4. Although the client now considers the user logged in- subsequent api calls to the server continue to provide the jwt token, which confirm the userid and signature with the same public key (note this may be a different server than the one which provided the initial token). Therefore, most meaningful operations (like change password) are still vetted server side, albeit with the same token as the one provided to clients. (i.e. a client can display whatever it wants, but real action truly confirms with the appropriate public key. Identifying data on the user, other than their id, requires an api call as well- to further ensure clients behave nicely)

Is there anything wrong with this picture? It seems oauth2 insists on some additional call - i.e. the mantra that oauth is authorization, not authentication, and so an additional call must be made (such as "get profile") before we consider the user properly authenticated.

Why is that? What advantages would oauth2 have over this methodology for this specific use case?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.