Tag Info

New answers tagged

0

Depending on how you will implement your application you can create a resource/API to generate a token as @Telastyn said (or you can use an authorization server - a different application to generate and validate these tokens) and pass it as a header field (usually people use the Authorization header) and your API check it's validity (in the same application ...


3

In general: User logs into some authentication system. Authentication system provides a token that effectively says "Authentication System X asserts that you are Bob, until 3:00 PM 8/31/2015 UTC". User then passes that token as metadata (header, some data envelope) to the various APIs. The various APIs look at it and decide if they trust Authentication ...


1

Is it necessary/sound to add the token to a database or can I just use the payload to identify the user? I think both approaches are fine. I've implemented token based authentication in .Net, and we put all identity related information in the token. I would argue it's more scalable, especially for a web farm. All the authentication information we need ...


0

It's not clear if your customer's website is using authentication. If you want a Single Sign On (SSO) solution, you'll need to find a common identity provider for both websites or look into identity federation. You probably want to look at supporting some kind of token based authentication scheme. You'll need a Security Token Service (STS) like for example ...


0

Your token should contain the users id and a hash. If the hash matches the JWT, you're fine (as long as nobody knows the private key your are using to create that hash).


1

First of all, don't put REST above solving problems efficiently. In order for clients to be able to log in you need to somehow store some state. Whether or not you consider this to be against the REST mantra doesn't really matter, you need to do it anyway. You could make digitally signed tokens containing all session information, and not store those on the ...


5

The statelessness of REST refers to the side of the server. If you pass around your token in every request this becomes part of the state that is being sent from the client and therefore does not violate the statelessness of your server. This differs from, for example, managing state on the server where you keep information in the session server-side. A ...



Top 50 recent answers are included