New answers tagged

0

Access Tokens are according to the RFC supposed to be limited access. Rather than worrying about where to store something of high value where the server might be compromised, it's better to simply limit the duration of access to the token. This is spelled out specifically in the RFC for bearer tokens: Issue short-lived bearer tokens: Token servers ...


2

If the request to the 3rd party API is through your server, then store the access token in the database tied to the user, encrypted with a key that is stored as an environment variable. If the database is compromised, the tokens are safe. (Bonus, encrypt the tokens with a key that is generated and stored on the mobile app.) If the request to the 3rd party ...


5

The main advantage of a refresh token is that it is easier to detect if it is compromised. Consider these two scenarios: A single long-lasting auth token is used. A short duration auth token is used, and a long-lasting refresh token periodically requests a new auth token once the previous one has expired. In scenario 1, if the auth token is compromised ...


1

Your client_id is like your username or e-mail address you use to authenticate your application/service to OAuth. It's not exactly top-secret, but putting it out in the public domain might also be undesirable. Especially if you're going to combine it in a list along with the client_name and redirect_uri it becomes a little dangerous. Because you're giving ...


2

You seem to be confusing authentication with authorisation. OAuth is chiefly about authorisation and has various flows to support different scenarios and use cases, one in particular which overlaps with your question supports user / resource owner password based authentication for authorising the requesting application access to some set of resources. As ...


1

Tokens and passwords are really very different things. But you haven't specified in your question what you are really asking. You mention OAuth in the subject line of your question but then don't mention it again in the body of the question. OAuth has different kinds of tokens in its spec, depending on what sub-spec you're talking about and what kind of ...


2

If you're in control of both the client and the server and you can ensure that both tokens are always transmitted securely, there is no drawback in using the same token for both. Normally, the refresh token is the critical token to protect, as this allows indefinite access to the application. It is also easier to control which transports this is transmitted ...


2

Some issues I can think of are: Exhausting the request limit, preventing any user's depending on that token from using it Violating the terms of service agreement by sharing a token which is supposed to remain secret/in the possession of a single user If the API is subject to such a vulnerability, exploitation of 'session fixation', where another user ...


0

The token that you are speaking about is not generated in the mobile app. It is generated in the 3rd-party authentication servers and passed to your mobile app. Your mobile app has to pass it back to the servers to validate your apps's authorization. Regarding security of the token, assuming that you are using SSL, you can pass the token in either a query ...



Top 50 recent answers are included