I don't see it mentioned anywhere in the 2.0 spec, is nonce not used by OAuth 2 and if not, now does it prevent replay attacks?
The 1.0 spec states:
3.3. Nonce and Timestamp
The timestamp value MUST be a positive integer. Unless otherwise specified by the server's documentation, the timestamp is expressed in the number of seconds since January 1, 1970 00:00:00 GMT.
A nonce is a random string, uniquely generated by the client to allow the server to verify that a request has never been made before and helps prevent replay attacks when requests are made over a non-secure channel. The nonce value MUST be unique across all requests with the same timestamp, client credentials, and token combinations.
To avoid the need to retain an infinite number of nonce values for future checks, servers MAY choose to restrict the time period after which a request with an old timestamp is rejected. Note that this restriction implies a level of synchronization between the client's and server's clocks. Servers applying such a restriction MAY provide a way for the client to sync with the server's clock; alternatively, both systems could synchronize with a trusted time service. Details of clock synchronization strategies are beyond the scope of this specification.
This is captured in a separate spec. See OAuth 2.0 Threat Model and Security Considerations for details/answers :)
Related
I'm using the Dailymotion API which uses Oauth2, their client tokens expire in 36000 seconds (10 hours), so I thought of creating new tokens for every call with the refresh token URL provided. Also, I didn't find any warnings in the documentation preventing me from doing this, is this a bad practice?
creating a new token on every requests is not the best way to proceed.
During your request, you can check (ex: with a "try") if your access token has expired then request new one with your given refresh token only if necessary.
If you are using a language like PHP, Python, Javascript, ... you can save much time using the available SDKs that already implement these mechanisms.
cf. https://developer.dailymotion.com/tools/sdks/
Yes, it is a bad practice, even though it's feasible. Authorization Servers might impose rate limiting on your client so that at some point you won't be able to refresh the token.
The access token must have expiration time for security reasons. If anyone manages to get hold of that token they will be able to use it only for the specified time. Good practice is to have as short expiration times as possible - e.g. 5 or 15 minutes. The 10 hours used by Dailymotion is a bit much, in my opinion, but it's their decision.
Refresh tokens should be kept securely by your client and you usually need a client secret to make a refresh request. This means that generally it's much harder for an attacker to get hold of a refresh token (or use it once they manage to steal it).
I am implementing 'sign in with google' or 'Google Sign In' on a webapp of mine. The google api allows a nonce to be used to prevent replay attacks, but fails to inform the max (or min) length of the nonce.
Looking at the: data-nonce
from this doc: https://developers.google.com/identity/gsi/web/reference/html-reference#data-nonce
Any help would be great
I sent a message off to my contacts at Google waiting to hear their response. First part of this answer was my own research.
That being said I started digging around in the RFC for OAuth and the only mention I found worth wild would be the following. (My experience with the Google Oauth team says that they like to follow the RFC guidelines as they are accepted industry standard.)
NonceNotes
15.5.2. Nonce Implementation Notes
The nonce parameter value needs to include per-session state and be unguessable to attackers. One method to achieve this for Web Server Clients is to store a cryptographically random value as an HttpOnly session cookie and use a cryptographic hash of the value as the nonce parameter. In that case, the nonce in the returned ID Token is compared to the hash of the session cookie to detect ID Token replay by third parties. A related method applicable to JavaScript Clients is to store the cryptographically random value in HTML5 local storage and use a cryptographic hash of this value.
The fact that they suggest storing it in a session cookie would then lead to the max limit being at the very least the max size of a session cookie which would give us something like this.
However i seem to remember something that allowed you to a cookie value across multiple cookies. That this would again lead me back to your assumption which would be this is probably going to be a limitation applied by each OAuth server.
I think we still need to wait to hear back from Google.
paraphrased response from Google
Google does not explicitly limit nonce size. An idea would be to
constrain it by the max support JWT size. However this may very by browser
, devices and networking infrastructure.
They have also updated the documentation found here to reflect that.
I understood why Access Tokens have to be expired (here is the topic), but I am a bit confused about the purpose of the expires_in:
expires_in seems to be less useful than a fixed time, since there are delay in network operations and extra computation as well. Why don't we simply use a standard time (like Unix timestamp or ISO 8601)?
As in that topic, if we are assuming Access Tokens are very short-lived, are we going to "bomb" the OAuth2 server with refresh token for every operation?
We are securing our webAPI using 'OAuth'. All request comes with OAuth token in header. To validate the token, we use Identity provider's public key. All works well.
I have a question. I believe this is not the right (and secure way), but don't know why.
In place of validating it with the public key every time, we can validate it once and for next subsequent requests, Why can't we store this token in cache (with emailId as key) and for all subsequent hits, we can compare it with the token store in cache.
Thanks in advance.
That's all fine and most Resource Servers would do exactly this. Typically one would calculate and store the hash of the access token for storage optimization reasons.
Note that you can do this safely assuming there's some lifetime that you can extract from the token and you will store the (hash of the) token not beyond that lifetime.
I think it depends on the character of the access token. If the token has a fixed life time that cannot change and its validity is verified just by checking its cryptographic signature (something like a JSON Web Token), then you can safely cache the verification results (if it brings you some speed advantage).
But access tokens are often revocable and it's necessary to validate them at the authorization server. The endpoint for access token info and verification didn't use to be part of OAuth2 spec, but it's in RFC now as "Introspection endpoint" - https://www.rfc-editor.org/rfc/rfc7662
Still, if there are many requests coming, even revocable tokens may be safe to cache for a short period of time (few seconds). But it depends on the character of your application.
I am developing an oAuth2 server and I've stumbled upon this question.
Lets suppose a scenario where my tokens are set to expire within one hour. On this timeframe, some client goes through the implicit auth fifty times using the same client_id and same redirect_uri. Basically same everything.
Should I give it the same accessToken generated on the first request on the subsequent ones until it expires or should I issue a new accessToken on every request?
The benefits of sending the same token is that I won't leave stale and unused tokens of a client on the server, minimizing the window for an attacker trying to guess a valid token.
I know that I should rate-limit things and I am doing it, but in the case of a large botnet attack from thousands of different machines, some limits won't take effect immediately.
However, I am not sure about the downsides of this solution and that's why I came here. Is it a valid solution?
I would rather say - no.
Reasons:
You should NEVER store access tokens in plain text on the Authorization Server side. Access tokens are credentials and should be stored hashed. Salting might not be necessary since they are generated strings anyway. See OAuth RFC point 10.3.
Depending how you handle subsequent requests - an attacker who knows that a certain resource owner is using your service and repeat requests for the used client id. That way an attacker will be able to impersonate the resource owner. If you really return the same token then at least ensure that you authenticate the resource owner every time.
What about the "state" parameter? Will you consider requests to be the "same" if the state parameter is different? If no then a botnet attack will simply use a different state every time and force you to issue new tokens.
As an addition - generally defending against a botnet attack via application logic is very hard. The server exposing your AS to the internet should take care for that. On application layer you should take care that it does not go down from small-bandwidth attacks.
You can return the same access_token if it is still valid, there's no issue with that. The only downside may be in the fact that you use the Implicit flow and thus repeatedly send the - same, valid - access token in a URL fragment which is considered less secure than using e.g. the Authorization Code flow.
As a thumb rule never reuse keys, this will bring additional security in the designed system in case of key capture
You can send different access token when requested after proper authentication and also send refresh token along your access token.
Once your access token expires, you should inform user about that and user should re-request for new access token providing one-time-use refresh token previously provided to them skipping need for re-authentication, and you should provide new access token and refresh token.
To resist attack with fake refresh token, you should blacklist them along with their originating IP after few warnings.
PS: Never use predictable tokens. Atleast make it extremely difficult to brute force attacks by using totally random, long alpha-numeric strings. I would suggest bin2hex(openssl_random_pseudo_bytes(512)), if you are using php.