How to authorise request Azure REST API? - azure

I am creating a program to drop CDN cache. And so I did as documentation said I still get this:
{
"error": {
"code": "AuthenticationFailedInvalidHeader",
"message": "Authentication failed. The 'Authorization' header is provided in an invalid format."
}
}
So it basically says that the Authentication token itself is malformatted (not wrong or expired). Even though I did as documentation suggested.
My Request-Response flow looks like this (I obfuscated real data):
REQUEST
POST /subscriptions/29bdq1a7-348b-48fe-b9e6-b90c432892ff/resourceGroups/cdn-4/providers/Microsoft.Cdn/Profiles/CDN-3-Premium/endpoints/custom-endpoint.azureedge.net/purge?api-version=2015-06-01 HTTP/1.1
Content-Length: 90
User-Agent: GuzzleHttp/6.1.1 curl/7.35.0 PHP/7.0.2-2+deb.sury.org~trusty+1
Host: management.azure.com
Authorization: SharedAccessSignature uid=56c6d48a66904d02ce030003&ex=2017-02-19T11:41:00.0000000Z&sn=9wBsmFuP1ps01rt8nVlvsiAIdJMOqNsmGaiXUlfT35RxOvWAjHHcSIQdJA8v9wGvX4bJgX5fu1QyqVG6y9iQ6Q==
Content-Type: application/json
{
"ContentPaths": [
"/uploads/static/ads_en.json",
"/pic2.jpg"
]
}
RESPONSE
HTTP/1.1 401 Unauthorized
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
WWW-Authenticate: Bearer authorization_uri="https://login.windows.net/c87x6f33-af21-4461-a5b1-29647d8e9281", error="invalid_token", error_description="The authentication scheme of SharedAccessSignature is not supported."
x-ms-failure-cause: gateway
x-ms-request-id: 3514027b-e731-411c-b8es-cdf77d636284
x-ms-correlation-request-id: 3514137b-e731-411c-b8ee-cdf77d636284
x-ms-routing-request-id: WESTEUROPE:20160219T110919Z:3514037b-e731-411c-b7ee-cdf77d636184
Strict-Transport-Security: max-age=31536000; includeSubDomains
Date: Fri, 19 Feb 2016 11:09:19 GMT
Connection: close
Content-Length: 150
{"error":{"code":"AuthenticationFailedInvalidHeader","message":"Authentication failed. The 'Authorization' header is provided in an invalid format."}}\
Can you suggest the way to solve it?

Part of the confusion I think is that there are two distinct Azure Management APIs (and nothing to do with Azure API Management).
There is the "Service Management" APIs and the Azure Resource Manager APIs (ARM).
The base URL you are using is for the ARM APIs and they don't use Shared Access Signatures.
The best article around on calling the ARM APIs directly is here,
http://blog.davidebbo.com/2015/12/calling-arm-using-plain-rest.html

Related

Office 365 SharePoint API with App Only token returns 401

I'm trying to call the Office 365 SharePoint API at tenant.sharepoint.com with an App Only token, but am getting a 401 response with the message:
The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework SDK documentation and inspect the server trace logs.
As this is in Office 365, I don't have access to the server to configure it and turn on error messages as suggested in the error message.
I have set up my Azure AD App Registration for app-only access, as described here, including the read and write managed metadata and manage all site collections application permissions.
I request the app-only token like so:
POST https://login.microsoftonline.com/f48cf683-1ba8-469a-82b5-930241ed093d/oauth2/token HTTP/1.1
host: login.microsoftonline.com
content-type: application/x-www-form-urlencoded
content-length: 1071
Request-Context: appId=cid-v1:a8ad1180-5e49-43f7-99e1-3d07c1ffa794
Connection: close
grant_type=client_credentials&client_id=a0e75d70-178a-48c3-94a9-4be5d97ea0c5&
client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&
client_assertion=*xxx*&resource=https%3A%2F%2Fpeterreayqa.sharepoint.com
(Assertion *xxx* omitted)
I get the response back:
HTTP/1.1 200 OK
Cache-Control: no-cache, no-store
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/10.0
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
x-ms-request-id: 03fa7b0e-d725-4730-b20c-26ff0e6e4200
P3P: CP="DSP CUR OTPi IND OTRi ONL FIN"
Set-Cookie: fpc=AfblxFAuBLNAo-WGH3FHRtau4ePVAQAzNMUKpE_WCA; expires=Fri, 21-Dec-2018 11:25:29 GMT; path=/; secure; HttpOnly
Set-Cookie: x-ms-gateway-slice=003; path=/; secure; HttpOnly
Set-Cookie: stsservicecookie=ests; path=/; secure; HttpOnly
Date: Wed, 21 Nov 2018 11:25:29 GMT
Connection: close
Content-Length: 1420
{"token_type":"Bearer","expires_in":"3599","ext_expires_in":"3599","expires_on":"1542803129","not_before":"1542799229","resource":"https://peterreayqa.sharepoint.com","access_token":"*xxx*"}
(Token *xxx* omitted)
Then when I try to call the SharePoint API:
POST https://peterreayqa.sharepoint.com/sites/Sage-NewSharePointTest/sageData/_vti_bin/sites.asmx HTTP/1.1
Authorization: Bearer *xxx*
User-Agent: ISV|Sage|OverDriveUserManagement/1.2
Content-Type: text/xml
SOAPAction: http://schemas.microsoft.com/sharepoint/soap/GetUpdatedFormDigestInformation
X-RequestForceAuthentication: true
Host: peterreayqa.sharepoint.com
Content-Length: 356
Expect: 100-continue
Accept-Encoding: gzip, deflate
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<GetUpdatedFormDigestInformation xmlns="http://schemas.microsoft.com/sharepoint/soap/" />
</soap:Body>
</soap:Envelope>
(Token *xxx* from previous response is omitted)
I get the following response:
HTTP/1.1 401 Unauthorized
Content-Length: 453
P3P: CP="ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI TELo OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI"
WWW-Authenticate: Bearer realm="f48cf683-1ba8-469a-82b5-930241ed093d",client_id="00000003-0000-0ff1-ce00-000000000000",trusted_issuers="00000001-0000-0000-c000-000000000000#*,D3776938-3DBA-481F-A652-4BEDFCAB7CD8#*,https://sts.windows.net/*/,00000003-0000-0ff1-ce00-000000000000#90140122-8516-11e1-8eff-49304924019b",authorization_uri="https://login.windows.net/common/oauth2/authorize"
x-ms-diagnostics: 3001000;reason="There has been an error authenticating the request.";category="invalid_client"
SPRequestGuid: 3e83a49e-40a8-0000-3740-5cec03406519
request-id: 3e83a49e-40a8-0000-3740-5cec03406519
MS-CV: nqSDPqhAAAA3QFzsA0BlGQ.0
Strict-Transport-Security: max-age=31536000
X-FRAME-OPTIONS: SAMEORIGIN
SPRequestDuration: 25
SPIisLatency: 1
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 16.0.0.8314
X-Content-Type-Options: nosniff
X-MS-InvokeApp: 1; RequireReadOnly
X-MSEdge-Ref: Ref A: 8C79E743EAB84728B1865357085F3AA0 Ref B: LON21EDGE1413 Ref C: 2018-11-21T11:28:12Z
Date: Wed, 21 Nov 2018 11:28:11 GMT
{"error_description":"The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework SDK documentation and inspect the server trace logs."}
Has anyone encountered this before?
Two suggestions:
First, make sure an Admin has 'Granted' the requested permissions
for the relevant app registration in the Azure portal. In the
article you linked above, they used a Powershell command to do so. If you are using the Azure portal API, it's a separate button.
Also, confirm that the self-signed security certificate was
correctly added to the Azure app registration manifest. You can do
so by downloading the manifest for the relevant Azure app
registration, and opening to view the entries. This article should
help:
https://blogs.msdn.microsoft.com/bobgerman/2017/06/25/calling-sharepoint-csom-from-azure-functions-part-2/

DocuSign Integrator Key is not found or disabled

I created a new developer account on DocuSign, generated the integrator key. Now i am trying to submit a GET request for retrieving account information but I keep getting error message "Integrator key is not found or disabled"
Below is my request which I am submitting using fiddler"service integration authentication" :
Raw http request
GET https://www.docusign.net/restapi/v2/login_information HTTP/1.1
X-DocuSign-Authentication: {"Username": "MyEmail","Password": "MyPassword","IntegratorKey": "IntegratorKeyCreatedFromAdminConsole"}
Host: www.docusign.net
Response:
HTTP/1.1 401 Unauthorized
Cache-Control: no-cache
Content-Length: 128
Content-Type: application/json; charset=utf-8
X-DocuSign-TraceToken: 4694b892-09cb-41aa-b5fa-307d226e9dd0
Date: Tue, 10 Jan 2017 16:26:33 GMT
Strict-Transport-Security: max-age=31536000; includeSubDomains
{
"errorCode": "PARTNER_AUTHENTICATION_FAILED",
"message": "The specified Integrator Key was not found or is disabled."
}
Thank you for your help!!
The URL you are trying to access is a production URL. Your integrator key only exists in DEMO, so update the URL to:
https://demo.docusign.net/restapi/v2/login_information
DocuSign should update their documentation at https://docs.docusign.com/esign/ When they talk about getting the baseURL they specify to go to the production url. They don't mention they have a URL for their demo system. Also their CURL sample does not work for DOS CURL. One has to use " and escape the json " with \ for example
curl -H "X-DocuSign-Authentication:{\"Username\": \"bob#example.com\",\"Password\": \"xxx\",\"IntegratorKey\": \"your_key\"}" https://www.docusign.net/restapi/v2/login_information

Cannot access OpenId UserInfo endpoint on Azure (AADSTS90010: JWT tokens cannot be used with the UserInfo endpoint)

I'm trying to access the OpenId UserInfo endpoint for a user on an Office365 Azure tenant, with the following GET:
GET https://login.windows.net/common/openid/userinfo HTTP/1.1
Authorization: Bearer eyJ0eXAiOiJ(...remainder deleted for brevity...)
Host: login.windows.net
The response fails with "400 Bad Request", and a more specific error "AADSTS50063: Credential parsing failed. AADSTS90010: JWT tokens cannot be used with the UserInfo endpoint"
HTTP/1.1 400 Bad Request
Cache-Control: no-cache, no-store
Pragma: no-cache
Content-Type: text/html
Expires: -1
Server: Microsoft-IIS/8.5
x-ms-request-id: ef5c8a50-69b5-40f1-ac5f-9c0fc5180aa2
x-ms-gateway-service-instanceid: ESTSFE_IN_6
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000; includeSubDomains
P3P: CP="DSP CUR OTPi IND OTRi ONL FIN"
WWW-Authenticate: Bearer correlation_id="e5c613a0-0a21-40e1-9ef6- eacf77580608", error="invalid_request", error_codes="[50063, 90010]", error_description="AADSTS50063: Credential parsing failed. AADSTS90010: JWT tokens cannot be used with the UserInfo endpoint.%0d%0aTrace ID: ef5c8a50-69b5-40f1-ac5f-9c0fc5180aa2%0d%0aCorrelation ID: e5c613a0-0a21-40e1-9ef6-eacf77580608%0d%0aTimestamp: 2015-02-20 14:13:42Z", timestamp="2015-02-20 14:13:42Z", trace_id="ef5c8a50-69b5-40f1-ac5f-9c0fc5180aa2"
Set-Cookie: x-ms-gateway-slice=productionb; path=/; secure; HttpOnly
Set-Cookie: stsservicecookie=ests; path=/; secure; HttpOnly
X-Powered-By: ASP.NET
Date: Fri, 20 Feb 2015 14:13:40 GMT
Content-Length: 0
The bearer token used is a non-expired access token that works fine for other operations, such as retrieving Exchange emails.
Furthermore, when I use an identical GET to the openid userinfo endpoint at "https://www.googleapis.com/plus/v1/people/me/openIdConnect" (as part of a gmail access scenario), it works fine
Am I doing anything wrong here? Thanks for any help!
Some extra info:
-Already tried using the id_token instead of the access_token, but this makes no difference.
-the Oauth scopes used are "profile email"
-the resources requested are "https://outlook.office365.com/"
-the client application is a native app and has enabled all delegated permissions for both "Windows Azure AD" and "Office 365 Exchange Online"
The Azure AD user info endpoint does not support the use of the regular JWT access tokens at this time. Instead, you can acquire a user info specific access token by not specifying any resource in a request to the token endpoint. You can think of the user info endpoint as a resource in its own right, which requires a special token format.
For example, in the authorization code case:
GET request to https://login.windows.net/common/oauth2/authorize?... without a resource parameter, and acquire an authorization_code
POST request to https://login.windows.net/common/oauth2/token using the authorization_code, also without a resource parameter. Receive an access token for the user info endpoint.
GET request to https://login.windows.net/common/openid/userinfo passing the access token in the header as Authorization: Bearer AAAB(...rest of token...)

AADSTS50001: Getting exception while trying to access token from Azure AD by using ADAL from Console client

Getting exception while trying to access token from Azure AD by using ADAL from Console client.
Steps:
I have configured Azure AD with my Web API application localhost:44307.
Added the required configuration for Client Id, Client Key.
Followed the work around by changing manifest suggested in this link.
https://www.google.com/search?q=AADSTS50001+%2B+azure+AD+athentication&oq=AADSTS50001+%2B+azure+AD+athentication&aqs=chrome..69i57.10202j0j7&sourceid=chrome&espv=210&es_sm=93&ie=UTF-8#q=AADSTS50001&safe=active
ADAL Version Using: Microsoft.IdentityModel.Clients.ActiveDirectory 2.6.0-alpha
Console App Code:
void GetToken()
{
clientId = "be6b055a-4efc-222a-2187-49657e6f4f1b";
string ClientKey = "c/uIMlsqn9SzJLKKyBle42Ym+tgcaC2tbMlWxJQawE";
string ClientCredential clientCred = new ClientCredential(clientId, ClientKey);
authenticationContext = new AuthenticationContext("https://login.windows.net/MyDevAD.onmicrosoft.com");
authenticationResult = authenticationContext.AcquireToken("https://mylocalwebapiapp.com/", clientCred);
....
}
Fiddler Input:
POST https: //login.windows.net/MyDevAD.onmicrosoft.com/oauth2/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
client-request-id: 53262b17-1234-4ed9-bdb3-748d332eb44b
return-client-request-id: true
x-client-SKU: .NET
x-client-Ver: 2.6.0.0
x-client-CPU: x64
x-client-OS: Microsoft Windows NT 6.3.9600.0
Host: login.windows.net
Content-Length: 185
Expect: 100-continue
Connection: Keep-Alive
grant_type=client_credentials&resource=https%3A%2F%2Flocalhost%3A44307%2F&client_id=be6b055a-4efc-408a-8187-42137e6f4f1b&client_secret=c%2FuIMlsqn9SzJLKKyBle123Ym%2BtgcaC3tbMlWxJQawE%3D
Fiddler Output:
HTTP/1.1 400 Bad Request
Cache-Control: no-cache, no-store
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
Set-Cookie: x-ms-gateway-slice=ProductionB; path=/
x-ms-request-id: e89741b2-570d-44f6-9e71-6533b083abcd
client-request-id: 35262b17-4771-4ed9-bdb3-748d332eb33b
X-Content-Type-Options: nosniff
X-Powered-By: ARR/3.0
X-Powered-By: ASP.NET
Date: Tue, 01 Apr 2014 19:05:51 GMT
Content-Length: 438
{"error":"invalid_resource","error_description":"AADSTS50001: Resource 'https://mylocalwebapiapp.com/' is not registered for the account.\r\nTrace ID: e89741b2-570d-44f6-9e71-6533b083cdad\r\nCorrelation ID: 35262b17-4771-4ed9-cddb3-748d332eb44b\r\nTimestamp: 2014-04-01 19:05:53Z","error_codes":[50001],"timestamp":"2014-04-01 19:05:53Z","trace_id":"e89741b2-570d-44f6-9e71-6533b083cdad","correlation_id":"35262b17-4771-4ed9-bdb3-748d332eb44b"}
Note: Posted URLS and ID's are faked ones.
We should not have introduced any changes. I would recommend to double check that you assigned to your client app the correct permissions for accessing your web API. Please note that your app is getting a token with its own credentials, hence you need to assign app permissions directly (as opposed to delegated permissions).
HTH
V.

Clarification on REST APIs around user management in an account

I recently created a docusign developer account and integrator key and was playing with docusign REST APIs and had some questions
I can retrieve full list of users under my account by using following REST call.
https://demo.docusign.net/restapi/v2/accounts/<accountid>/users?additional_info=true
However if I try and retrieve a specific user (other than the one I am passing in my X-Docusign-authentication) header i get http 400 error with message that the "Invalid UserId. UserId specified in request uri does not match authenticated user"
https://demo.docusign.net/restapi/v2/accounts/<accountid>/users/0d51a699-b17a-48b7-95b6-1e9e9806deb6
In both cases i am sending the following header.
X-DocuSign-Authentication: <DocuSignCredentials><Username>{0}</Username><Password>{1}</Password><IntegratorKey>{2}</IntegratorKey></DocuSignCredentials>
I am surprised that while I can read all users fine, I cannot just read one specific user. Surely it doesn't seem like this is security thing since I can read the user via one API but not the other using the same auth token.
What am i missing?
I guess I can go the route of SOBO (Send on behalf of functionality), but I wanted to confirm if above behavior is expected.
Update#1
: I went the SOBO approach and now i get a different error (USER_NOT_ACCOUNT_ADMIN) as shown below
GET /restapi/v2/accounts/{accountid}/users/0fe29a55-5564-42a9-b09d-cbe699db13dd HTTP/1.1
Authorization: bearer {token for authenticating user}
X-DocuSign-Act-As-User: {operating user's email}
Accept: application/json
Host: demo.docusign.net
Connection: Keep-Alive
HTTP/1.1 401 Unauthorized
Cache-Control: no-cache
Content-Length: 100
Content-Type: application/json; charset=utf-8
Date: Thu, 17 Oct 2013 21:18:32 GMT
Strict-Transport-Security: max-age=7776000; includeSubDomains
{
"errorCode": "USER_NOT_ACCOUNT_ADMIN",
"message": "User is not an account administrator."
}
I also tried the second SOBO approach of getting a oauth token for the operating user but got back http 400 error with below message
{
"error": "invalid_request",
"error_description": "An OAuth2 error occurred."
}
So while i can get an oauth token for the autheitcating user, i am not able obtain oauth token for the operating user or act on their behalf.
I have made sure that authenticating user is "Account Administrator" and has both "apiAccountWideAccess" and "•allowSendOnBehalfOf" set to true. The only thing set to "false" is "canSendAPIRequests". My account id in sandbox environment is "601565a7-e9c7-463b-9d7c-622aed905ea8" Any ideas?
Update#2
Instead of generating oauth tokens on behalf of both authenticating user and operating user, i tried passing below header and i can finally get another user's profile and update another user's profile.
X-DocuSign-Authentication: <DocuSignCredentials><SendOnBehalfOf>{operating userid}</SendOnBehalfOf><Username>{authenticating userid}</Username><Password>{authenticating user's password}</Password><IntegratorKey>{developer's integrator key}</IntegratorKey></DocuSignCredentials>
Great!
So here is status of what works and what doesn't.
Works with no SOBO header anywhere
GET /restapi/v2/accounts/357938/users?additional_info=true // Read all users
GET /restapi/v2/accounts/357938/users?email=someshchandraatwork#gmail.com&additional_info=true // Read single user by email
POST /restapi/v2/accounts/357938/users // Add users
DELETE /restapi/v2/accounts/357938/users // Close users
*Works with SOBO in X-DocuSign-Authentication header
PUT /restapi/v2/accounts/357938/users/74a021e1-3090-4843-b9ab-cceb7cd119f4/profile // Update user's profile
GET /restapi/v2/accounts/357938/users/74a021e1-3090-4843-b9ab-cceb7cd119f4/profile // Read user's profile
Still doesn't work with or without SOBO**
GET /restapi/v2/accounts/357938/users/74a021e1-3090-4843-b9ab-cceb7cd119f4/settings
GET /restapi/v2/accounts/357938/users/74a021e1-3090-4843-b9ab-cceb7cd119f4
In both not working cases i get following error
Without SOBO i get error that userid doesn't match autheitcating user.
With SOBO i get error than user is not an account admin
I would very much appreciate any help in resolving the not working cases. I can provide more detaisl as needed.
Secondly I want to implement a scenario where I can deactivate a user in an account so they can no longer log into docusign. And subsequently I would like to enable that user back again with same permission that they had before they were disabled.
I see that user has a "userStatus" field and was wondering if I can use that to de-activate the user and then re-activate if needed. If this is supported then what value would correspond to deactivating the user?
The other thing I note is that on DELETE a user, the user is only soft-deleted since I can still query the user with the status "CLOSED". That would solve my "deactivate" problem. However I was not sure if there is a way to reactivate them back again after the user has been "closed"?
I believe this might be an account administration issue. I'm not sure why but I looked at your account settings from DocuSign's side and I saw the "Send on Behalf of" was not checked on your account- which is weird since it seems you have access to the setting in your Console -> Preferences settings.
But in either case I'm wondering if the setting I just enabled on your account has solved your issue, as it might have.
I'm also not sure about the user info portion of your question, let me see if I can come up with anything for that and I'll edit my answer once I do.
In reply to Erign's post above.
Anyone who is an account admin should be able to modify/add/delete users in an account. I'm not sure if your SOBO steps are correct though, can you confirm that you are following THESE STEPS exactly? If so, at which step do you run into issues or get an error?– Ergin5 mins ago
Yes i am following those steps. I am able to generate oauth token for the autheitcating user , but get an error when doing the same for the operating user. Below are my request and responses.
1. REQUEST FOR AUTH TOKEN FOR AUTHENTICATING USER
POST /restapi/v2/oauth2/token HTTP/1.1
Accept: application/json
Content-Type: application/x-www-form-urlencoded
Host: demo.docusign.net
Content-Length: 139
Expect: 100-continue
Connection: Keep-Alive
grant_type=password&client_id={integratorykey}&username={authenticating user's email}&password={authenticating user's password}&scope=api
RESPONSE
HTTP/1.1 200 OK
Cache-Control: no-cache
Content-Length: 100
Content-Type: application/json; charset=utf-8
Date: Thu, 17 Oct 2013 22:57:26 GMT
Strict-Transport-Security: max-age=7776000; includeSubDomains
{
"access_token": "{authenticating user's token}",
"token_type": "bearer",
"scope": "api"
}
2. REQUEST FOR AUTH TOKEN FOR OPERATING USER
POST /restapi/v2/oauth2/token HTTP/1.1
Authorization: bearer {authenticating user's token}
Accept: application/json
Content-Type: application/x-www-form-urlencoded
Host: demo.docusign.net
Content-Length: 137
Expect: 100-continue
grant_type=password&client_id={integratorykey}&username={operating user's id}&password={empty}&scope=api
RESPONSE
HTTP/1.1 400 Bad Request
Cache-Control: no-cache
Content-Length: 87
Content-Type: application/json; charset=utf-8
Date: Thu, 17 Oct 2013 22:57:29 GMT
Strict-Transport-Security: max-age=7776000; includeSubDomains
{
"error": "invalid_request",
"error_description": "An OAuth2 error occurred."
}

Resources