Google access token expiration time - oauth-2.0

When I obtain an access_token from the Google API, it comes with an expires_in value. According to the documentation, this value indicates "The remaining lifetime of the access token".
What are the units of this value?

The spec says seconds:
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-22#section-4.2.2
expires_in
OPTIONAL. The lifetime in seconds of the access token. For
example, the value "3600" denotes that the access token will
expire in one hour from the time the response was generated.
I agree with OP that it's careless for Google to not document this.

Have a look at: https://developers.google.com/accounts/docs/OAuth2UserAgent#handlingtheresponse
It says:
Other parameters included in the response include expires_in and
token_type. These parameters describe the lifetime of the token in
seconds...

Since there is no accepted answer I will try to answer this one:
[s] - seconds

From Google OAuth2.0 for Client documentation,
expires_in -- The number of seconds left before the token becomes invalid.

Related

Microsoft Graph Authentication error AADSTS70000 code_verifier does not match code_challenge

I have multiple pages that authenticate via Microsoft Graph. One doesn't work. It returns a (400) Bad Request, with the error_description of AADSTS70000: The provided 'code_verifier' input value does not match the original 'code_challenge.'
All Redirect URL's are defined under my Microsoft Applications. Except for the URI, they are the same.
I cannot find anything that actually says what they mean be code_verifier and code_challenge. Since I never pass any parms by those names, they must be referring to one of the other parms being passed in before and after the login. But I really need to know what they refer to so I can attempt to figure out what the real issue seems to be.
I have seen several posts claiming a trailing slash is required, but I don't have this on any of my Redirect URI's, and most of them work.
Here is the initiating request:
href="https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id={redacted}&response_mode=form_post&response_type=code&redirect_uri=https://wrmatthiesen.com/ApprovedContact/InviteeSignup.aspx&scope=openid offline_access User.Read Calendars.ReadWrite Contacts.Read Mail.Send& nonce=mauth:-6:Y:Y;1b803d44-f70b-4fed-b6c3-bc3afdb55646& state=mauth:-6:Y:Y;1b803d44-f70b-4fed-b6c3-bc3afdb55646"
Here is the follow up request once I have received the code:
code=Mabb3f2bb-25b0-8e3b-541e-9763dd1e4136&redirect_uri=https%3a%2f%2fwrmatthiesen.com%2fApprovedContact%2fInviteeSignup.aspx&grant_type=authorization_code&client_id={redacted}&client_secret={redacted}&scope=openid+offline_access+User.Read+Calendars.ReadWrite+Contacts.Read+Mail.Send
1) Your initial request included several unencoded strings that include special characters.
2) You have a couple of space your query string: & nonce and & state
You're first URL should look like this:
https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=00000000-0000-0000-0000-000000000000&response_mode=form_post&response_type=code&redirect_uri=https://wrmatthiesen.com/ApprovedContact/InviteeSignup.aspx&scope=openid+offline_access+User.Read+Calendars.ReadWrite+Contacts.Read+Mail.Send&nonce=mauth%3A-6%3AY%3AY%3B1b803d44-f70b-4fed-b6c3-bc3afdb55646&state=mauth%3A-6%3AY%3AY%3B1b803d44-f70b-4fed-b6c3-bc3afdb55646
The components here being:
client_id: 00000000-0000-0000-0000-000000000000
response_mode: form_post
response_type: code
redirect_uri: https%3A%2F%2Fwrmatthiesen.com%2FApprovedContact%2FInviteeSignup.aspx
scope: openid+offline_access+User.Read+Calendars.ReadWrite+Contacts.Read+Mail.Send
nonce: mauth%3A-6%3AY%3AY%3B1b803d44-f70b-4fed-b6c3-bc3afdb55646
state: mauth%3A-6%3AY%3AY%3B1b803d44-f70b-4fed-b6c3-bc3afdb55646
On the second call, your POST body looks correct:
code: Mabb3f2bb-25b0-8e3b-541e-9763dd1e4136
redirect_uri: https%3A%2F%2Fwrmatthiesen.com%2FApprovedContact%2FInviteeSignup.aspx
grant_type: authorization_code
client_id: 00000000-0000-0000-0000-000000000000
client_secret: 00000000-0000-0000-0000-000000000000
scope: `openid+offline_access+User.Read+Calendars.ReadWrite+Contacts.Read+Mail.Send
I have been passing in a nonce parameter since I have been doing this. I just made it match my state parameter for ease. In this situation, my nonce looked like this: "nonce=mauth:-6:Y:Y;b5a41fdb-4b42-494e-85e1-8c193006d444".
When I dropped everything except the "mauth:", it worked.
I then dropped the nonce all together, and it still worked. So, for now, I will not pass the nonce in.

Hacked. How can a hacker get to the individual-url (token) of my users?

How would you think a hacker is doing the following, and how would you prevent (looking for some helpfull links, keywords or assessment of the sitution)?
Their is a website where users can register and get an invitation Email. The invaitation link (https) contains the token. It looks like 'https://www.example.com/token/123456' (123456 is the token).
It seems that a day after my users clicked on this link, someone else uses the same links too.
How is this possible and how can I prevent this sort of hack?
Thanks
EDIT:
Sorry I should have given more information. I can eliminate the opinion that it is not just a try of random token variations. Why? The exact token is used a day after one of the user had use the link. The token is a hash token of more that 20 characters.
They can just run a script to try any numerical value in the token value.
it's easy. How long is your token? I would also suggest using a hash token rather than a simple numerical one to limit automatic processing, as the "hack" is scripting to try a number, gets a result - store the result, and then number = number + 1;
Edit: What evidence do you have you've been hacked? What happens in your script once someone has clicked the token link?
A simple logic to apply could be:
define a string pattern. like: secretconstant%email
hash the string and now you have the token (and save it)
create your invitation url with the token
If someone call your service with random token you can reject them because your information system don't have saved that token.
Then if you have the token you must discard it so the link will not be valid anymore.
You could check also if the email used in the registration is the same used for calculate the token.. so you may block the registration!

iOS. Implement incremental param for requests?

Link to API
There is a param "nonce":
An additional security element must be passed into the post:
nonce - All requests must also include a special nonce POST parameter with incrementing integer. The integer must always be
greater than the previous requests nonce value.
Of course I can implement it via integer param and perform ++ operation each time I use it, but what to do if this value is less than it is required and it causes request error? For example if it was reset for example after application reinstall?
Suddenly I found a solution:
#((int)[[NSDate date] timeIntervalSince1970])
I saw in php they use microtime() function. I hope my function will give the same result

how to generate OAuth nonce in numeric format for getting followers

I want to get oAuth nonce for https://api.twitter.com/1.1/followers/list.json how can i get whether in php or iOS API
If the question is "How can I generate an OAuth nonce in Objective-C?", then you should start from OAuth specification section 3.3. Nonce and Timestamp.
For an Objective-C implementation, you can have a look at STTwitter's code for generating nonces.
Basically, you can create a random string with the CFUUIDCreateString(). Taking the first 32 characters is enough.

What are the characteristics of an OAuth token?

How many characters long can an oauth access token and oauth access secret be and what are the allowed characters? I need to store them in a database.
I am not sure there are any explicit limits. The spec doesn't have any.
That said, OAuth tokens are often passed as url parameters and so have some of the same limitations. ie need to be properly encoded, etc.
OAuth doesn't specify the format or content of a token. We simply use encrypted name-value pairs as token. You can use any characters in token but it's much easier to handle if the token is URL-safe. We achieve this by encoding the ciphertext with an URL-safe Base64.
As most people already pointed out. The OAuth specification doesn't give you exact directions but they do say...
cited from: https://datatracker.ietf.org/doc/html/draft-hammer-oauth-10#section-4.9
"Servers should be careful to assign
shared-secrets which are long enough,
and random enough, to resist such
attacks for at least the length of
time that the shared-secrets are
valid."
"Of course, servers are urged to err
on the side of caution, and use the
longest secrets reasonable."
on the other hand, you should consider the maximum URL length of browsers:
see: http://www.boutell.com/newfaq/misc/urllength.html
If you read the spec, it says,
The authorization server issues the registered client a client
identifier - a unique string representing the registration
information provided by the client. The client identifier is not a
secret; it is exposed to the resource owner, and MUST NOT be used
alone for client authentication. The client identifier is unique to
the authorization server.
The client identifier string size is left undefined by this
specification. The client should avoid making assumptions about the
identifier size. The authorization server SHOULD document the size
of any identifier it issues.
Second, Access Token should be sent as header, not as a URL param.
Authorization: Bearer < token>.
An OAuth token is conceptually an arbitrary-sized sequence of bytes, not characters. In URLs, it gets encoded using standard URL escaping mechanisms:
unreserved = ALPHA, DIGIT, '-', '.', '_', '~'
Everything not unreserved gets %-encoded.
I'm not sure whether you just talk about the oauth_token parameter that gets passed around. Usually, additional parameters need to be stored and transmitted as well, such as oauth_token_secret, oauth_signature, etc. Some of them have different data types, for example, oauth_timestamp is an integer representing seconds since 1970 (encoded in decimal ASCII digits).
Valid chars for OAuth token are limited by HTTP header value restrictions as OAuth token is frequently sent in HTTP header "Authorization".
Valid chars for HTTP headers are specified by https://www.rfc-editor.org/rfc/rfc7230#section-3.2.6. Alternatively you may check HTTP header validating code of some popular HTTP client libs, for example see Headers.checkNameAndValue() util of OkHttp framework: https://github.com/square/okhttp/blob/master/okhttp/src/main/java/okhttp3/Headers.java
And this is not all. I wouldn't include HTTP header separator (; and many others) and whitespace symbols (' ' and '\t') and double quote (") (see https://www.rfc-editor.org/rfc/rfc7230#section-3.2.6) as it would require to escape OAuth token before using in HTTP header. Frequently tokens are used by humans in curl test requests, and so good token generators don't add such characters. But you should check what characters may produce Oauth token generator with which your service is working before making any assumptions.
To be specific, even if Oauth spec doesn't say anything, if you are using java and mysql then it will be 16 characters as we generally generate the tokens using UUID and store it as BINARY(16) in the database. I know these details as I have recently done the development using OAuth.

Resources