got it. so i only need to access the DB (or access an endpoint that verify
the existence of the user) at the login. from that moment, the JWT token is
self sufficient and I no longer need any DB (for
authentication/authorization purposes).
Thanks!
On Wednesday, August 5, 2015 at 2:17:51 PM UTC
At the client side you'll have to store de JWT Token somewhere, somehow.
At the server side of the authentication service you'll need the user
information stored somewhere, somehow, to check password and create the JWT
token.
When I use JWT Token, I usually put the user information as the payload
You have your user accounts in a db. When a users logs in, you verify his
account. You store every information you might need in the future in the
claim of the JWT. You create the JWT and send it back to the user. With
this JWT the user can now log in from anywhere, anytime until the JWT
expires. Y
Thank you Alexander!
so maybe I don't even need to store anything in a DB?
On Tuesday, August 4, 2015 at 6:13:51 AM UTC-7, Alexander Behrens wrote:
>
> > JWT token is created with user id, stored in a DB and JWT is returned
> to the app.
>
> Do you mean that user id stored in a DB or do you sto
> JWT token is created with user id, stored in a DB and JWT is returned to
the app.
Do you mean that user id stored in a DB or do you store the JWT in a DB? If
you are storing the JWT, there is no point of using JWT :)
> The app will store the JWT in the localStorage
I always thought this was a
We use OneLogIn for SSO and also SalesForce. We would like to have a single
auth service that will take care of authentication and authorization to all
our apps.
Is this diagram looks like a good approach? http://i.imgur.com/Ji1I1P4.png -
Here is the suggested flow:
email/password form -> auth
