Tag Info

New answers tagged

0

To answer your questions: 1) How do you handle a situation with a compromised token secret which is shared between a client and the server? Add an expiry date to your token. Make the sure the token cannot be used after the expiry time. But this doesn't prevent unauthorized access within the token's expiry period. So, to overcome this problem you can ...


0

The use of encrypted OAuth tokens is good approach to satisfying the security requirements in RFC-6749 section 10. Encrypted OAuth tokens are in common use, Facebook is a good example. OAuth tokens expire based on the expires_in parameter. Which means that a given token would be valid for a short time after the user logs out, which is very low risk issue ...


2

To specifically address the scenario, Facebook doesn't need to wait until a user logs in to capture an OAuth token. Since you're trusting Facebook as your authentication provider, they can generate a valid OAuth token for any user in their system anytime they please. Given that, there are three potentially correct answers here. This is not a threat, ...


1

I found quite useful the diagram represented under the openid website OpenID Connect Protocol Suite. You can click on the boxes in order to see the specification


2

Yes and no. If done right it will be, but what you are describing is simply an authentication cookie. I would suggest to not reinvent the wheel. The framework/programming language that you use probably already have a way to manage authentication cookie. I would go with that instead of creating it yourself.


1

It depends on whether the encryption mechanism you're using provides confidentiality (like AES in bare CBC mode) or or confidentiality and integrity *like AES in CBC mode with an HMAC, or AES-GCM) Just because your data is encrypted doesn't mean that it can't be tampered with in a way that you can't detect. It must be both encrypted and authenticated, ...


0

You don't need half of those parts. Adding them will only create a more complicated system, with more room for failures. You could do this: Use certificate pinning on the device This ensures that the device is talking to your server, and make the work very hard for any third party trying to read the data stream. Using SSL, send login and password to the ...


1

Depending on different flows that you want or have to use (authorization code, implicit grand, resource owner password or client credentials flows) you might need an authorization token and definitively an access token. The authorization token can be stored in the database and can have TTL of more days whereas the access token (around 5 min or configurable) ...


0

For the most part, a token-based authentication solution would be preferable, however Basic Auth does offer maximum interoperability and downward compatibility. Any client (even a shell script with curl) could consume your service easily, as long as they had valid credentials.


1

It seems like the only security advantage is that if using one-time code flow, browser component and server component of the client each get their own token. In pure server side flow, only server gets the token and web application flow only client gets the token. Sending token from client to server, and vice versa, exposes end user to a certain risk. Using ...



Top 50 recent answers are included