Outlook Dev Center - OAuth Sandbox stoped working with mail. When i try to send :
https://outlook.office.com/api/v2.0/me/mailfolders/inbox/messages?$top=10
i'm getting :
HTTP/1.1 403 Forbidden
Transfer-Encoding: chunked
request-id: 72bb8456-b708-4395-b20b-070f59203571
X-CalculatedBETarget: AM4PR06MB1602.eurprd06.prod.outlook.com
X-BackEndHttpStatus: 403
x-ms-diagnostics: 2000008;reason="The token contains not enough scope to make this call.";error_category="invalid_grant"
OData-Version: 4.0
X-DiagInfo: AM4PR06MB1602
X-BEServer: AM4PR06MB1602
X-FEServer: AM4PR01CA0018
X-MSEdge-Ref: Ref A: C76DC482B3B948DCA89EA29991DAC69F Ref B:CFF0022456998571B7B1C5143CD90D48 Ref C: Sun Oct 30 05:12:00 2016 PST
Cache-Control: private
Date: Sun, 30 Oct 2016 12:12:00 GMT
Set-Cookie: exchangecookie=7f60ed49643e4ce098a0af5830de4eec; expires=Mon, 30-Oct-2017 12:12:00 GMT; path=/; HttpOnly
Server: Microsoft-IIS/8.5
WWW-Authenticate: Bearer client_id="00000002-0000-0ff1-ce00-000000000000", trusted_issuers="00000001-0000-0000-c000-000000000000#*", token_types="app_asserted_user_v1 service_asserted_app_v1", error="invalid_token"
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
{
"error": {
"code": "ErrorAccessDenied",
"message": "Access is denied. Check credentials and try again."
}
}
after some investigation i noticed that OAuth Sandbox is not requesting email read write permission.
Is it a bug?
I don't reproduce this. The Sandbox does request read/write permission via the Mail.ReadWrite.Shared scope, assuming you are authorizing with your own account.
If you click the Authorize using Sandbox Account it only requests Mail.Read.Shared, but that is sufficient scope to do a GET on https://outlook.office.com/api/v2.0/me/mailfolders/inbox/messages?$top=10.
So to answer your question, no, I don't believe this is a bug. :) Can you provide more info on exactly what you're doing when you get this error? Are you logging in with an Office 365 account or a Microsoft account (outlook.com, Hotmail.com, etc.)?
Update: The problem was caused by Microsoft accounts not understanding the Mail.ReadWrite.Shared and ignoring it. The sandbox has been updated to request both the Mail.ReadWrite and the Mail.ReadWrite.Shared scopes.
Related
Trying to achieve this using Delphi 10 Seattle/Intraweb 15.0.23
Tried the sample code and received a 401 error. Have installed chilkat and unlocked chilkat API for 30 day trial run.
Used Global unlock code from here
https://www.example-code.com/delphidll/global_unlock.asp
Using Docusign code from here
https://www.example-code.com/delphidll/docusign_request_signature_via_email.asp
Thanks
Response Received
Response Body:
{}
Response Status Code = 401
Response Header:
Cache-Control: no-cache
Content-Length: 249
Content-Type: application/xml; charset=utf-8
X-DocuSign-TraceToken: e863f1f6-253b-437a-a4e8-fd1815d6b262
Date: Thu, 26 Mar 2020 19:15:52 GMT
Vary: Accept-Encoding
Failed.
This is an authentication issue. Not sure how you obtained your accessToken, but the error is "The access token provided is expired, revoked or malformed."
You need to ensure you obtain your accessToken from the correct endpoint and that is for the correct account. If you are using JWT - check your RSA private key.
Also, the delphi code is a bit outdated and uses API 2.0, you should use 2.1
We are building a smart home app using actions on google for the google home. Our app requires signing into our system to be able to access the users devices so they can control them using their voice over google home. Our user backend is built using AWS Cognito. We are using API.AI as part of the Google Home app.
I have configured the Cognito OAUTH2 endpoint and the actions on google app to work with each other using the auth code flow and varying scope's but there is something I am missing. When I attempt to link the user account to the Google Home app i get redirected to our login page. After filling out the user details I'm returned to the Google Home 'Discover' tab but there is a message across the bottom that states: ‘Bad response from IdP in Auth Code Exchange’.
I also have tried it using Google's OAUTH2 playground. It seems that when using that I am able to get the code from our OATUH server, but when trying to exchange the code for a token i get the following error:
HTTP/1.1 400 Bad Request
Strict-transport-security: max-age=31536000 ; includeSubDomains
X-content-type-options: nosniff
X-application-context: application:prod:8443
Transfer-encoding: chunked
Set-cookie: XSRF-TOKEN=35f58337-76f4-4993-a0c9-93429134ea42; Path=/; Secure; HttpOnly
Expires: 0
Server: Server
Connection: keep-alive
X-amz-request-id: 284d862e-b021-4079-b5f5-3cbce675983c
X-xss-protection: 1; mode=block
Pragma: no-cache
Cache-control: no-cache, no-store, max-age=0, must-revalidate
Date: Wed, 23 Aug 2017 13:51:42 GMT
X-frame-options: DENY
Content-type: application/json;charset=UTF-8
{
"error": "invalid_client"
}
I have checked and rechecked the client ID and client secret etc and cannot find any errors.
Does anyone have any idea how I might fix this problem?
Thanks in advance
ok，may be i know the reason.....If you use aws cognito ...
According to this doc (http://docs.aws.amazon.com/cognito/latest/developerguide/token-endpoint.html)
Authorization
If the client was issued a secret, the client must pass its client_id and client_secret in the authorization header through Basic HTTP authorization. The secret is Basic Base64Encode(client_id:client_secret).
they need put client and client sectet in header ...
Then I use aws http proxy caught the request of google progress .
Method request headers: {X-Cloud-Trace-Context=d7b6b9b8239965baf69acab659e80a01/13879251242019662389, CloudFront-Viewer-Country=US, CloudFront-Forwarded-Proto=https, CloudFront-Is-Tablet-Viewer=false, CloudFront-Is-Mobile-Viewer=false, User-Agent=google-oauth-playground AppEngine-Google; (+http://code.google.com/appengine; appid: s~oauth2playground), X-Forwarded-Proto=https, CloudFront-Is-SmartTV-Viewer=false, Host=en75z5h2rb.execute-api.us-east-1.amazonaws.com, Accept-Encoding=gzip, deflate, X-Forwarded-Port=443, X-Amzn-Trace-Id=Root=1-5a0fcef2-09197cd86a625ad47d78f0b7, Via=1.1 d63a8908759a2f4775b3f672ebf823cc.cloudfront.net (CloudFront), X-Amz-Cf-Id=nFdLK97vAS5HvmpNYkPpbUMOB4bCaM6pScHWTAReAnonLg1gXF7hSg==, X-Forwarded-For=107.178.195.199, 54.182.238.53, content-type=application/x-www-form-urlencoded, CloudFront-Is-Desktop-Viewer=true}
There are no Authorization in request header. So the Cognito will return back
"error": "invalid_client"
According this OAUTH2.0 spec (https://www.rfc-editor.org/rfc/rfc6749#section-2.3.1)
I have already ask AWS support. They said:
Thanks for contacting AWS Support and providing us with detailed references. I would be happy to assist with your question regarding Cognito supporting client credentials in the request-body.
After reading through the OAUTH2.0 Standards RFC 6749 [0], It looks like including the client credentials in the request-body is not recommended. Here's an excerpt on the spec:
"Including the client credentials in the request-body using the two parameters is not recommended and should be limited to clients unable to directly utilize the HTTP Basic authentication scheme (or other password-based HTTP authentication schemes)."
I've tried several times, but I can't use the Google PlayGround tool with the Google People API v1.
Request / Response
POST /oauth2/v4/token HTTP/1.1
Host: www.googleapis.com
Content-length: 278
content-type: application/x-www-form-urlencoded
user-agent: google-oauth-playground
code=4%2FhQlhA-MiWKhcmHWVUddb8TmiaVEDdMd_3lDHid9eYBc&redirect_uri=https%3A%2F%2Fdevelopers.google.com%2Foauthplayground&client_id=111243977462-pc15rhq33ojuc7i54ce3qd8upj6mtnc3.apps.googleusercontent.com&client_secret=ozWubBNz1iKdykitcK757UOo&scope=&grant_type=authorization_code
HTTP/1.1 401 Unauthorized
Content-length: 74
X-xss-protection: 1; mode=block
X-content-type-options: nosniff
Transfer-encoding: chunked
Expires: Sun, 16 Jul 2017 14:54:42 GMT
Vary: Origin, X-Origin
Server: GSE
-content-encoding: gzip
Cache-control: private, max-age=0
Date: Sun, 16 Jul 2017 14:54:42 GMT
X-frame-options: SAMEORIGIN
Alt-svc: quic=":443"; ma=2592000; v="39,38,37,36,35"
Content-type: application/json; charset=UTF-8
Www-authenticate: Bearer realm="https://accounts.google.com/"
{
"error_description": "Unauthorized",
"error": "unauthorized_client"
}
I've already followed the tips below:
1. Delete the whitespace in the 'OAuth Client ID' and 'OAuth Client secret' in the OAuth 2.0 configuration of Google PlayGround
2. Define in the manager API the authorized redirection URI for: https://developers.google.com/oauthplayground
3. Verify in the Manager API is enabled on the Dashboard
Could someone help me with any more tips for me to try to solve the problem?
Below is a description of what I did on Google Playground:
Step 1 Select & authorize APIs
1. I select Google API v1 and framework https://www.googleapis.com/auth/contacts.readonly
2. Click the 'Authorize APIs'
Step 2 Exchange authorization code for tokens
1. Click the 'Oauth 2.0 Configuration'
2. Click on the 'Use your own OAuth credentials'
3. Enter the 'OAuth Client ID' and the 'OAuth Client secret'
4. Click the button: 'Exchange authorization code for tokens'
I do not know if it has to do with the issue, but I noticed that the list of applications connected to my account does not appear 'OAuth 2.0 Playground'. But I have the 'Google APIs Explorer' where I successfully tested access to my contacts (Google People API).
Go to settings by clicking the gear icon. Set the following as defined below and then tick the 'Use you own Oauth credentials' and fill in the client_id and client_secret of your Google OAuth app :
Add google.com in the authorized domain list of your app's OAuth consent screen.
Click on the application for which you want to configure for the next step:
Make sure to also add 'https://developers.google.com' in the Authorized JavaScript origins and 'https://developers.google.com/oauthplayground' in the Authorized redirect URIs[click 'save' below once added]:
Then click 'Authorize APIs' after selecting the appropriate access requirements:
You should get a prompt and then authorize it [incase of a safety warning, proceed ahead and click allow for the permissions requested]
Once done you should have an authorization code using which you can generate your token[access token and refresh token, we get a refresh token as we specified 'offline' in the access-type settings earlier]. This is a one time auth code[you would get an invalid_grant if you try to re-use it], store the access token and refresh token for talking to google APIs, new access token can be generated using the refresh token.
We have managed SNS service for Samsung mobile(feature phone, camera).
We are facging issues regarding ClientLogin API. When we request ClientLogin and then we receive response: 404 Error.
This API was only a few hours before the operation.
We can't upgrade to OAuth2, because of the device firmware update is not possible.
Is there remains to be still available?
The formats of request and response are as follows
####################### REQUEST #######################
POST /accounts/ClientLogin HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 87
Host: www.google.com
Content-Type: application/x-www-form-urlencoded
Proxy-Connection: Close
Connection: Close
Email=&Passwd=&service=lh2&source=SamsungMobile+SNS+Gateway
####################### RESPONSE #######################
HTTP/1.1 404 Not FoundContent-Type:text/plain
X-Frame-Options:DENY
Cache-control:no-cache, no-store
Pragma:no-cache
Expires:Mon, 01-Jan-1990 00:00:00 GMT
Date:Wed, 27 May 2015 00:09:55 GMT
X-Content-Type-Options:nosniff
X-XSS-Protection:1; mode=block
Content-Length:65
Server:GSE
Alternate-Protocol:443:quic,p=1
Connection:close
https://developers.google.com/accounts/docs/AuthForInstalledApps
As you can see in the link you posted Google Identity Platform
Important: ClientLogin has been officially deprecated as of April 20,
2012 and is no longer available as per our deprecation policy. We
encourage you to migrate to OAuth 2.0 as soon as possible.
ClientLogin is a deprecated authentication protocol and is being turned down on April 20, 2015. At that time, ClientLogin requests will no longer be answered. If you have existing applications that use ClientLogin, we encourage you to migrate to OAuth. The ClientLogin support in this library will be removed in the next major release.
Its not going to work anymore you will have to upgrade or retire the application.
ClientLogin has been shut down.
This is my first post on stackoverflow. Here it goes.
I've built a server-side PHP application that involves reading/making changes to one users's YouTube account (changes to caption files). The user is authenticated with OAuth 2. I have been storing the refresh_token and making refresh requests successfully when the access_token expires.
But now, I seem to be getting an error, which coincidentally correlates with two things:
User's upload of a new video
Sunday nights
I don't know if that means anything.
The error happens when trying to refresh the access token and I'm using the same way of refreshing the token as I have previously. Here are the details:
Error message:
[status code] 400
[reason phrase] Bad Request
[url] https://accounts.google.com/o/oauth2/token
[request] POST /o/oauth2/token HTTP/1.1
Host: accounts.google.com
User-Agent: Guzzle/2.8.6 curl/7.24.0 PHP/5.3.10
Content-Type: application/x-www-form-urlencoded
client_id=442147492209.apps.googleusercontent.com&client_secret=D7eLQ5b0Mo1Y8uZ30ReWYwls&grant_type=refresh_token&refresh_token=1%2FCLvAt8V_d9sZznpg5YZdJlOJ58ufbHKL4F5Lw8PiJOg
[response] HTTP/1.1 400 Bad Request
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: Fri, 01 Jan 1990 00:00:00 GMT
Date: Tue, 02 Oct 2012 16:28:24 GMT
Content-Type: application/json
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Server: GSE
Transfer-Encoding: chunked
{
"error" : "invalid_grant"
}
If you feel like looking at the source code, it's on github. Here's the relevant line number where refresh takes place: https://github.com/wellcaffeinated/yt-subtitle-explorer/blob/master/app/YTSE/OAuth/LoginManager.php#L330
(You'll notice that I've added a check for this error and ask the administrator to reauthorize the application... but this is far from ideal)
Other posts I've looked into were telling people to use approval_prompt=force... so I am doing that.
Edit:
My newest suspicion is that since I am requesting offline access (approval_prompt=force) every time the administrator logs in, I keep generating new refresh_tokens (which I don't record unless no others are available). Does google's OAuth have a maximum number of "active" refresh_tokens per application? Or something like that?
Thanks!
please check this from google developers pages:
If you receive an invalid_grant error response when attempting to use
a refresh token, the cause of the error may be due to the following
reasons:
Your server's clock is not in sync with NTP.
The refresh token limit
has been exceeded. Applications can request multiple refresh tokens to
access a single Google Analytics account. For example, this is useful
in situations where a user wants to install an application on multiple
machines and access the same Google Analytics account. In this case,
two refresh tokens are required, one for each installation. When the
number of refresh tokens exceeds the limit, older tokens become
invalid. If the application attempts to use an invalidated refresh
token, an invalid_grant error response is returned. The limit for each
unique pair of OAuth 2.0 client and Google Analytics account is 25
refresh tokens (note that this limit is subject to change). If the
application continues to request refresh tokens for the same
Client/Account pair, once the 26th token is issued, the 1st refresh
token that was previously issued will become invalid. The 27th
requested refresh token would invalidate the 2nd previously issued
token and so on.