Here is my code
$client = new Google_Client();
$client->setApplicationName("name");
$client->setClientId('id');
$client->setClientSecret('secret');
$client->addScope("https://www.googleapis.com/auth/userinfo.email");
$token_data = $client->verifyIdToken($token);
verifyIdToken is triggering 500 Internal Server Error if token is invalid. Can you help me to figure out how to get rid of that? And how can i verify the token is valid or not?
Never mind.
I had to use try-catch to catch exceptions. If token is invalid, it will trigger an exception.
Related
We have a java application that connects to ExactOnline for performing the operations.
The connection works fine for almost 9days and then it will start complaining about the below exception:
"Request from start.exactonline.nl returned an error (response code: 400, response: { "error":"invalid_grant","error_description":"Token is not allowed, because of invalid or empty chainId"
After encountering this error we have to force re-authorize the application by the user to get the new accessToken.
Now I am getting the below error as well:
"Request to token endpoint https://start.exactonline.nl/api/oauth2/token"
Any help would be appreciated.
The error message it's background and the solutions are explained at https://forums.invantive.com/t/exact-online-error-token-is-not-allowed-because-of-invalid-or-empty-chainid-on-exact-online/2226
When accessing Google-Drive, an access-token can expire and we can use the refresh-token to get a new access-token. There are a number of possible reasons though, that the refresh-token itself stops working or expires, see:
https://developers.google.com/identity/protocols/OAuth2#expiration
So my question, what happens if the refresh-token has expired after the 6 months, how can I detect it? Does the request for refreshing the access-token fail with 403 forbidden, or does it return a JSON containing an error message, or something else?
Unfortunately it is hard to find any information about this, and to test it out one has to wait for 6 month...
Solution:
Thanks to Gary Archers answer I could produce the situation with an invalid refresh-token and this is the response I got, maybe it helps somebody else:
HTTP-status-code: 400
JSON:
{
"error": "invalid_grant",
"error_description": "Bad Request"
}
Almost all implementations I've seen return a known error code of 'invalid_grant' that you can check for. It will look something like this, with the server returning a JSON response with an error field and an optional error_description. At this point you need to redirect the user to reauthenticate:
Is it ever expected to see a "500" status response during the final redirect from an OAuth2 provider?
server_error: Unable to issue redirect for OAuth 2.0 transaction
I'm trying to determine if this is ultimately the provider Auth0's error (it seems to be) or mine. If it were mine I'd expect a 400 series error. It is possible to have hooks or rules, could these result in 500-series errors in a scenario like this? I would also anticipate a more specific 500-error not 500 but another available number like 599 for lack of a better example.
My more specific case has something like:
new auth0.WebAuth({
domain: '....auth0.com'
,clientID: 'theid...'
,callbackUri: 'http://localhost:8080/'
,audience: 'http...',
,responseType: 'token id_token'
,scope: 'openid profile'
,leeway: 60
});
success then 500 for /login/callback?state=... on return
I misspelled the callback field, it should be redirectUri (not callbackUri above)! Auth0 tech support was kind enough to point this out.
I also asked about changing the error from 500 internal server error to 400 "Bad Request" to indicate a missing client-provided detail per my read of the details
https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
details for 400 (and the rest) https://www.rfc-editor.org/rfc/rfc7231#section-6.5.1
I am using the Thinktecture.IdentityModel 4.0 samples for WebApiSecurity. I've modified the AdfsSamlClient to use our ADFS Server. I am able to get a SAML token from out ADFS Server using
var channel = factory.CreateChannel();
var token = channel.Issue(rst) as GenericXmlSecurityToken;
Then I try to make the service call
var client = new HttpClient { BaseAddress = _baseAddress };
client.DefaultRequestHeaders.Authorization =
new AuthenticationHeaderValue("AdfsSaml", saml);
var response = client.GetAsync("identity").Result;
And get a 401 - Not Authorized call.
I am not sure how to debug this. I have tracing for Microsoft.IdentityModel, but it is only information level trace, no errors or warnings, and nothing I am able to use to debug.
The interesting part of the service trace:
1.
Description OnEndRequest is redirection to IdentityProvider '/WebHost/api/identity'
2.
Description CreateSignInRequest
BaseUri https://[ADFS...]/adfs/ls/
wa wsignin1.0
wtrealm https://[WorkStation...]/WebHost/
wctx rm=0&id=passive&ru=%2fWebHost%2fapi%2fidentity
3.
Description Redirecting to IdentityProvider: 'https://[ADFS...]/adfs/ls/?wa=wsignin1.0&wtrealm=https%3a%2f%2f[WorkStation...]%2fWebHost%2f&wctx=rm%3d0%26id%3dpassive%26ru%3d%252fWebHost%252fapi%252fidentity&wct=2013-09-30T17%3a35%3a04Z'
Thanks for any insight.
Main thing that springs to mind is to make sure the server knows how to handle the "AdfsSaml" scheme that you're using, so you'll want to make sure that your mapping is correct to your token handler.
One thing I tried was to create my own token handler, and mapped that as the token handler for the header. If you want, you can start with Thinktecture's own HttpSamlSecurityTokenHandler, and debug your way through that. Obviously, if it never hits it, then you've got a mapping issue somewhere.
I also found that if an exception was thrown in the ClaimsAuthenticationManager, it would report as unauthorized - even though the exception being thrown was something completely unrelated (in my case, an InvalidCastException). That stumped me for a while, because I hadn't realise that authentication had gotten so far down the pipeline and that validation of the token had actually been successful - I was just checking the HTTP response, which kept saying unauthorised - so make sure you're not being misled by anything trivial like that.
Getting authentication errors when I try and obtain my upload authorization token
https://developers.google.com/youtube/2.0/developers_guide_protocol_error_responses
Using a packet sniffer, my first error message is>
401 Token invalid - Invalid token: Cannot parse AuthSub token:
In addition to perhaps improperly formatted Auth key value, I'm wondering exactly what headers I should be including for my upload auth request.
I am using the following though think clientId has been deprecated
"Authorization", "GoogleLogin auth=\"" + authToken + "\""
"X-GData-Client", clientId
"X-GData-Key", "key=" + devKey
After changing
"Authorization", "AuthSub token="+authToken
to
Authorization", "GoogleLogin auth="+authToken
in my request I no longer get 'Cannot parse AuthSub token' error message but
I still get
Error #2032: Stream Error. URL: http://gdata.youtube.com/action/GetUploadToken
<errors>
<error>
<domain>yt:authentication</domain>
<code>Unknown</code>
</error>
</errors>
Stumped. Would really appreciate any feedback as I'm not even certain now where my error(s) exist!
ok working but not really sure how:)
Am using these 2 headers in my POST request to
'http://gdata.youtube.com/action/GetUploadToken'
"Authorization", "GoogleLogin auth="+authToken
"X-GData-Key", "key=" + devKey
And also needed to associate my youtube user developer credentials with a channel
https://groups.google.com/forum/#!msg/youtube-api-gdata/76x8vaADJWM/36O05FD7mC0J
A packet sniffer or at least adding support to read the XMl error responses is essential!
I resolved this problem by providing the correct developer key