I have implemented ntlmv2 for lync-server login in an custom made lync client.The message that I send to server is .....
(3rd register message)
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/TLS 19x.1xx.0.1xx:3246
From: <sip:lynctest8#example.com>;tag=2257063211;epid=22570632
To: <sip:lynctest8#example.com>
Call-ID: A2B000F95CB8XZRikcdYitb4QBvEr4P2
CSeq: 3 REGISTER
Contact: <sip:19x.1xx.0.1xx:3246;transport=tls;ms-opaque=28c9d310c1>;methods="INVITE, MESSAGE, INFO, OPTIONS, BYE, CANCEL, NOTIFY, ACK, REFER, BENOTIFY";proxy=replace;+sip.instance="<urn:uuid:6b6590c5-2a3f-5dee-ad87-5ab6694cf66d>"
Max-Forwards: 70
User-Agent: UCCAPI/4.0.7577.0 OC/4.0.7577.0 (Microsoft Lync 2010)
Supported: gruu-10, adhoclist, msrtc-event-categories
Supported: ms-forking
Supported: ms-cluster-failover
Supported: ms-userservices-state-notification
Ms-keep-alive: UAC;hop-hop=yes
Event: registration
Ms-subnet: 19x.1xx.0.0
Proxy-Authorization: NTLM qop="auth", realm="SIP Communications Service", opaque="8CEED616", targetname="lyncfe.example.com", version=4, gssapi-data="TlRMTVNTUAADAAAAGAAYAKgAAADGAMYAwAAAABAAEABYAAAALAAsAGgAAAAUABQAlAAAABAAEACGAQAAVYKQYgYBsR0AAAAPAAAAAAAAAAAAAAAAAAAAAG4AZQB5AGUAYgBhAGwAbABsAHkAbgBjAHQAZQBzAHQAOABAAG4AZQB5AGUAYgBhAGwAbAAuAGMAbwBtAEUAWQBFAEIAQQBMAEwALQBQAEMA9jYBMVaneo2SEFBrg1/YnLPWl4gGzCyjeTg+SJIb99jnRvh/xOM1KQEBAAAAAAAAAD9j2kfbzAGz1peIBswsowAAAAACABAATgBFAFkARQBCAEEATABMAAEADABMAFkATgBDAEYARQAEABgAbgBlAHkAZQBiAGEAbABsAC4AYwBvAG0AAwAmAGwAeQBuAGMAZgBlAC4AbgBlAHkAZQBiAGEAbABsAC4AYwBvAG0ABQAYAG4AZQB5AGUAYgBhAGwAbAAuAGMAbwBtAAcACABjQk/rRdvMAQAAAAAAAAAAGL4kYo+YoVBEmij7AkIylQ==" , crand="becdaa89", cnum ="1", response="0100000024A95BA08AA3947964000000"
Content-Length: 0
The response that I get from server is in log is......
TL_INFO(TF_COMPONENT) [0]05FC.02D0::01/25/2012-08:06:57.900.00000042 (SIPStack,CSIPMessage::CacheConnectionFlags:SIPMessage.cpp(1664))[0]( 00000000039B4DC0 ) From server [lyncfe.example.com] connection, flags [PeerInternal TrafficInternal 0xa0100c], CID [0x12300]
TL_INFO(TF_PROTOCOL) [0]05FC.02D0::01/25/2012-08:06:57.900.00000043 (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(125))$$begin_record
Trace-Correlation-Id: 4074196035
Instance-Id: 000018F0
Direction: incoming;source="internal edge";destination="external edge"
Peer: lyncfe.example.com:5061
Message-Type: response
Start-Line: SIP/2.0 401 Unauthorized
From: <sip:lynctest8#example.com>;tag=1672455111;epid=16724551
To: <sip:lynctest8#example.com>;tag=6E92C85AEBAC66461CD3D9E7FF35D674
CSeq: 3 REGISTER
Call-ID: CDEA0494B083GDXKgQYZ3IuhqvqePNLL
Date: Wed, 25 Jan 2012 08:06:57 GMT
WWW-Authenticate: NTLM realm="SIP Communications Service", targetname="lyncfe.example.com", version=4
WWW-Authenticate: TLS-DSK realm="SIP Communications Service", targetname="lyncfe.example.com", version=4, sts-uri="https://lyncfe.example.com:443/CertProv/CertProvisioningService.svc"
Via: SIP/2.0/TLS 19x.1xx.0.2xx:60027;branch=z9hG4bK72A5FBC9.AAC299504F0761A1;branched=FALSE;ms-received-port=60027;ms-received-cid=16B9100
Via: SIP/2.0/TLS 19x.1xx.0.1xx:3082;received=2xx.xx.1xx.1xx;ms-received-port=3082;ms-received-cid=12700
ms-diagnostics: 1000;reason="Final handshake failed";HRESULT="0xC3E93EC3(SIP_E_AUTH_UNAUTHORIZED)";source="lyncfe.example.com"
Server: RTC/4.0
Content-Length: 0
Message-Body: –
$$end_record
What is the problem here? Can you give any hints/solutions to solve it?
It most likely due to SSL handshake while end point "https://lyncfe.example.com:443/CertProv/CertProvisioningService.svc". Please check your client certs and also enable SSL debug to see what's happening during handshake.
Thanks, Everyone. My problem has been solved. It was GSS-API-data and auth-token generation problem.
Related
Etag is supported in SDK: https://sap.github.io/cloud-sdk/docs/java/features/odata/use-typed-odata-v4-client-in-sap-cloud-sdk-for-java/#handling-of-etags
So experimenting it by using BusinessPartner entity in S/4 EX.
But seems there's no If-Match header:
How come the header doesn't show up - any prerequisite with etag?
(entering on behalf of the implementation partner team)
I checked the VersionIdentifier of the response and it was not set to a value.
I also checked the response's JSON __metadeta and header, but there were no values that appeared to correspond to the ETag value.
[Code]
BusinessPartner bp1 = new DefaultBusinessPartnerService().getBusinessPartnerByKey(bpId).execute(dest);
log.debug("get 1: {}", bp1);
log.debug("get 1 VersionIdentifier: {}", bp1.getVersionIdentifier());
bp1.setOrganizationBPName1("SCP Update 1st:" + System.currentTimeMillis());
ODataUpdateResult result1 = new DefaultBusinessPartnerService().updateBusinessPartner(bp1).execute(dest);
log.debug("Update1 Http Status: {}", result1.getHttpStatusCode());
bp1.setOrganizationBPName1("SCP Update 2nd:" + System.currentTimeMillis());
bp1.setVersionIdentifier("dummy");
ODataUpdateResult result2 = new DefaultBusinessPartnerService().updateBusinessPartner(bp1).execute(dest);
log.debug("Update2 Http Status: {}", result2.getHttpStatusCode());
[Log]
get 1: BusinessPartner(super=VdmObject(customFields={}, changedOriginal...
get 1 VersionIdentifier: None
Update1 Http Status: 204
Update2 Http Status: 204
[GET Response JSON(__metadata) / Response Header]
(It has masked the IP address.)
"__metadata": {
"id": "https://xxx.xxx.xxx.xxx:xxxxxx/sap/opu/odata/sap/API_BUSINESS_PARTNER/A_BusinessPartner('1000001')",
"uri": "https://xxx.xxx.xxx.xxx:xxxxxx/sap/opu/odata/sap/API_BUSINESS_PARTNER/A_BusinessPartner('1000001')",
"type": "API_BUSINESS_PARTNER.A_BusinessPartnerType"
},
HTTP/1.1 200 OK
content-type: application/json; charset=utf-8
content-length: 3152
dataserviceversion: 2.0
sap-metadata-last-modified: Thu, 14 May 2020 23:58:07 GMT
cache-control: no-store, no-cache
sap-processing-info: ODataBEP=,crp=,RAL=,st=,MedCacheHub=SHM,codeployed=X,softstate=
sap-server: true
sap-perf-fesrec: 243070.000000
I tried setting the VersionIdentifier to a meaningless value in my test code (2nd update).
The update process seems to be successful, although the request header now has "If-Match" added to it.
(I was expecting the update to fail because the values never match, so I was hoping the update would fail.)
[2nd Update(setVersionIdenfifier)]
(It has masked some of the values.)
PATCH http://xxx.xxx.xxx.xxx:xxxxxx/sap/opu/odata/sap/API_BUSINESS_PARTNER/A_BusinessPartner(BusinessPartner='1000001') HTTP/1.1
x-csrf-token: xxx
Content-Type: application/json
Accept: application/json
If-Match: dummy
Authorization: Basic xxx
SAP-Connectivity-SCC-Location_ID: xxx
Proxy-Authorization: Bearer xxx
sap-language: en
sap-client: xxx
Content-Length: 55
If ETags are not part of OData service responses, then you should approach the IT/administrators who maintain the S/4 backend. The SAP Cloud SDK is only consuming the OData service. Unfortunately it can't leverage ETag support if it's disabled.
I'm using the Docusign Ruby SDK to make calls on the API. I have my code working when pointed to the developer docusign, when pointed to prod I'm getting the DocuSign_eSign::ApiError: Bad Request error.
I have already gotten my integration key/client id approved in production and I've also already done the authorization grant part, where you allow the integration key to send envelopes on a user's behalf. This has been done in dev and production.
desc 'Perform API call to list envelopes'
task list: :initialize do
options = DocuSign_eSign::ListStatusChangesOptions.new
options.from_date = (Date.today - 10).strftime('%Y/%m/%d')
options.status = 'completed'
#list_results = #envelopes_api.list_status_changes #account_id, options
end
desc 'Build list results hash'
task build_list_hash: :list do
#list_results_hash = []
#list_results.envelopes.each do |list_hash|
#list_results_hash << { envelope_id: list_hash.envelope_id, status: 'pending', archive_at: Time.now + (86400 *30) }
end
puts "List results hash:\n #{#list_results_hash}"
File.open(ENV['MASTER_LIST_FILE'], 'w') { |file| file.write(#list_results_hash.to_yaml) }
end
I expect the output to be a list of envelopes which is what happens when running on demo.docusign
Update: Thanks for showing me how to get logs. It seems the error is with GetUserProfileImage
GET https://na3-app.docusign.net:8832/restapi/v2.1/accounts/91608b5d-d418-4c45-89f0-cd088504f99d/users/63757e15-8365-4fb9-9e7d-d9a8309f8e94/profile/image
TraceToken: 996d3b3f-2857-47d6-9d75-26a75b6b0a37
Timestamp: 2019-10-17T20:58:32.0932823Z
Content-Length: 0
Connection: keep-alive
Accept: application/json;text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Encoding: gzipdeflatebr
Accept-Language: en-USen; q=0.5
Authorization: Bearer [omitted]
Host: na3-app.docusign.net
Referer: https://app.docusign.com/preferences/security
User-Agent: Mozilla/5.0(Windows NT 10.0; Win64; x64; rv:69.0)Gecko/20100101Firefox/69.0
x-docusign-clienttransactionid: fa4e1202-09a4-431b-9abf-fe4d00acf565
x-csrf-token: c34f42c5aad288063afc8a6615be03c9
x-forwarded-for: 170.140.186.226, 162.248.185.11
x-docusign-authentication: {"IntegratorKey":"[omitted]"}
x-docusign-prettyprint: false
content-transfer-encoding: base64
x-forwarded-for-martini: 170.140.186.226
x-docusign-diagnostics: {"storedProcedureEventLogThreshold":"300"}
x-docusign-timetrack: CONN_START,2019-10-17T20:58:31.946Z;;REQ_SENT,2019-10-17T20:58:31.950Z;REST0_Start,2019-10-17T20:58:32.0620315Z
x-docusign-correlationtoken: fa4e1202-09a4-431b-9abf-fe4d00acf565
X-SecurityProtocol-Version: TLSv1.2
X-SecurityProtocol-CipherSuite: ECDHE-RSA-AES256-GCM-SHA384
404 NotFound
Content-Type: application/json; charset=utf-8
Content-Length: 95
X-DocuSign-ClientTransactionId: fa4e1202-09a4-431b-9abf-fe4d00acf565
X-DocuSign-TimeTrack: CONN_START,2019-10-17T20:58:31.946Z;;REQ_SENT,2019-10-17T20:58:31.950Z;;REST0_Start,2019-10-17T20:58:32.0620315Z;REST0_End,2019-10-17T20:58:32.0932823Z
X-DocuSign-TraceToken: 996d3b3f-2857-47d6-9d75-26a75b6b0a37
{"errorCode":"RESOURCE_NOT_FOUND","message":"The URL provided does not resolve to a resource."}```
When I run this request using this azure library:
blobURL.PutBlob(ctx, strings.NewReader("Some text"), azblob.BlobHTTPHeaders{}, azblob.Metadata{"Foo": "/愛知県/bar"}, azblob.BlobAccessConditions{})
I get this error:
===== RESPONSE ERROR (ServiceCode=AuthenticationFailed) =====
Description=Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.
RequestId:daf8a672-001e-000e-2f4b-a033f3000000
Time:2018-02-07T19:38:09.6740273Z, Details:
AuthenticationErrorDetail: The MAC signature found in the HTTP request 'REDACTED' is not the same as any computed signature. Server used following string to sign: 'PUT
9
x-ms-blob-cache-control:
x-ms-blob-content-disposition:
x-ms-blob-content-encoding:
x-ms-blob-content-language:
x-ms-blob-content-type:
x-ms-blob-type:BlockBlob
x-ms-client-request-id:f18fd538-3780-4f62-5236-777ac244affa
x-ms-date:Wed, 07 Feb 2018 19:38:09 GMT
x-ms-meta-foo:/愛知県/bar
x-ms-version:2016-05-31
/MYACCOUNT/MYCONTAINER/ReadMe.txt
timeout:61.
PUT https://MYACCOUNT.blob.core.cloudapi.de/MYCONTAINER/ReadMe.txt?timeout=61
Authorization: REDACTED
Content-Length: [9]
User-Agent: [Azure-Storage/0.1 (go1.9.3; darwin)]
X-Ms-Blob-Cache-Control: []
X-Ms-Blob-Content-Disposition: []
X-Ms-Blob-Content-Encoding: []
X-Ms-Blob-Content-Language: []
X-Ms-Blob-Content-Type: []
X-Ms-Blob-Type: [BlockBlob]
X-Ms-Client-Request-Id: [f18fd538-3780-4f62-5236-777ac244affa]
X-Ms-Date: [Wed, 07 Feb 2018 19:38:09 GMT]
X-Ms-Meta-Foo: [/愛知県/bar]
X-Ms-Version: [2016-05-31]
--------------------------------------------------------------------------------
RESPONSE Status: 403 Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.
Content-Length: [936]
Content-Type: [application/xml]
Date: [Wed, 07 Feb 2018 19:38:09 GMT]
Server: [Microsoft-HTTPAPI/2.0]
X-Ms-Request-Id: [daf8a672-001e-000e-2f4b-a033f3000000]
exit status 1
Is this because "/愛知県/bar" != "/愛知県/bar"?
Do you see any way to set non-ascii character like "/愛知県/bar" as a metadata value?
Since you mentioned Go in the tag, I assume you are looking for using a transliterator, there is this one in github which you should try
: https://github.com/rainycape/unidecode
I'm trying to configure OpenBTS 4 to use Restcomm for SIP registrar, voice and SMS proxy. Looks like OpenBTS has a minimal SIP stack and expects not to be challenged when registering mobile devices as sip clients. I see this question addressed for FreeSwitch:
http://wiki.freeswitch.org/wiki/OpenBTS
Can Restcomm be configured to accept registration requests without auth challenge?
SIP message log:
21:52:14,743 INFO [gov.nist.javax.sip.stack.UDPMessageChannel] (Mobicents-SIP-Servlets-UDPMessageChannelThread-3) Setting SIPMessage peerPacketSource to: /192.168.1.22:5062
21:52:14,749 INFO [gov.nist.javax.sip.stack.SIPTransactionStack] (Mobicents-SIP-Servlets-UDPMessageChannelThread-3) <message
from="192.168.1.22:5062"
to="0.0.0.0:5080"
time="1417931534736"
isSender="false"
transactionId="z9hg4bkobtskvtocsucdsglutmh"
callId="001013e826c0010-e5a7615573939dc7"
firstLine="REGISTER sip:192.168.1.22 SIP/2.0"
>
<![CDATA[REGISTER sip:192.168.1.22 SIP/2.0
To: <sip:IMSI001010000000002#192.168.1.22:5080>
From: <sip:IMSI001010000000002#192.168.1.22:5080>;tag=OBTSiciuwjsxgdqsjsrb
Via: SIP/2.0/UDP 127.0.0.1:5062;branch=z9hG4bKOBTSkvtocsucdsglutmh;received=192.168.1.22
Call-ID: 001013e826c0010-e5a7615573939dc7
CSeq: 56410 REGISTER
Contact: <sip:IMSI001010000000002#127.0.0.1:5062>;expires=5400
P-Preferred-Identity: <sip:IMSI001010000000002#127.0.0.1>
P-PHY-Info: OpenBTS; TA=1 TE=0.294483 UpRSSI=-62.603565 TxPwr=20 DnRSSIdBm=-66 time=1417931534.143
P-Access-Network-Info: 3GPP-GERAN; cgi-3gpp=0010103e8000a
User-Agent: OpenBTS 4.0.0.8025 Build Date Mar 19 2014
Max-Forwards: 70
Content-Length: 0
]]>
</message>
21:52:14,755 INFO [org.mobicents.servlet.sip.core.dispatchers.InitialRequestDispatcher] (Mobicents-SIP-Servlets-UDPMessageChannelThread-3) Request event dispatched to RestComm
21:52:14,765 INFO [gov.nist.javax.sip.stack.SIPTransactionStack] (RestComm-akka.actor.default-dispatcher-31) <message
from="0.0.0.0:5080"
to="192.168.1.22:5062"
time="1417931534763"
isSender="true"
transactionId="z9hg4bkobtskvtocsucdsglutmh"
callId="001013e826c0010-e5a7615573939dc7"
firstLine="SIP/2.0 407 Proxy Authentication required"
>
<![CDATA[SIP/2.0 407 Proxy Authentication required
To: <sip:IMSI001010000000002#192.168.1.22:5080>;tag=20906605_eef5d580_57a5b08a_e058ce9c-9ea9-4cad-b6c5-372364a3afa9
Via: SIP/2.0/UDP 127.0.0.1:5062;branch=z9hG4bKOBTSkvtocsucdsglutmh;received=192.168.1.22
CSeq: 56410 REGISTER
Call-ID: 001013e826c0010-e5a7615573939dc7
From: <sip:IMSI001010000000002#192.168.1.22:5080>;tag=OBTSiciuwjsxgdqsjsrb
Server: TelScale Sip Servlets 7.0.2-SNAPSHOT
Proxy-Authenticate: Digest realm="192.168.1.22",nonce="36303031356338332d326635622d343"
Content-Length: 0
]]>
</message>
21:52:45,836 INFO [gov.nist.javax.sip.stack.UDPMessageChannel] (Mobicents-SIP-Servlets-UDPMessageChannelThread-4) Setting SIPMessage peerPacketSource to: /192.168.1.22:5062
21:52:45,841 INFO [gov.nist.javax.sip.stack.SIPTransactionStack] (Mobicents-SIP-Servlets-UDPMessageChannelThread-4) <message
from="192.168.1.22:5062"
to="0.0.0.0:5080"
time="1417931565828"
isSender="false"
transactionId="z9hg4bkobtscdqcajsutpuenhlc"
callId="001013e826c0010-e5a7615573939dc7"
firstLine="REGISTER sip:192.168.1.22 SIP/2.0"
>
<![CDATA[REGISTER sip:192.168.1.22 SIP/2.0
To: <sip:IMSI001010000000002#192.168.1.22:5080>
From: <sip:IMSI001010000000002#192.168.1.22:5080>;tag=OBTSzyvbgcivyilvjqxe
Via: SIP/2.0/UDP 127.0.0.1:5062;branch=z9hG4bKOBTScdqcajsutpuenhlc;received=192.168.1.22
Call-ID: 001013e826c0010-e5a7615573939dc7
CSeq: 56411 REGISTER
Contact: <sip:IMSI001010000000002#127.0.0.1:5062>;expires=5400
P-Preferred-Identity: <sip:IMSI001010000000002#127.0.0.1>
P-PHY-Info: OpenBTS; TA=1 TE=0.385417 UpRSSI=-66.000000 TxPwr=28 DnRSSIdBm=-48 time=1417931565.071
P-Access-Network-Info: 3GPP-GERAN; cgi-3gpp=0010103e8000a
User-Agent: OpenBTS 4.0.0.8025 Build Date Mar 19 2014
Max-Forwards: 70
Content-Length: 0
]]>
</message>
21:52:45,847 INFO [org.mobicents.servlet.sip.core.dispatchers.InitialRequestDispatcher] (Mobicents-SIP-Servlets-UDPMessageChannelThread-4) Request event dispatched to RestComm
21:52:45,851 INFO [gov.nist.javax.sip.stack.SIPTransactionStack] (RestComm-akka.actor.default-dispatcher-31) <message
from="0.0.0.0:5080"
to="192.168.1.22:5062"
time="1417931565849"
isSender="true"
transactionId="z9hg4bkobtscdqcajsutpuenhlc"
callId="001013e826c0010-e5a7615573939dc7"
firstLine="SIP/2.0 407 Proxy Authentication required"
>
<![CDATA[SIP/2.0 407 Proxy Authentication required
To: <sip:IMSI001010000000002#192.168.1.22:5080>;tag=12394044_eef5d580_57a5b08a_5b523e6e-471b-4e99-93c0-ad56b68b2b93
Via: SIP/2.0/UDP 127.0.0.1:5062;branch=z9hG4bKOBTScdqcajsutpuenhlc;received=192.168.1.22
CSeq: 56411 REGISTER
Call-ID: 001013e826c0010-e5a7615573939dc7
From: <sip:IMSI001010000000002#192.168.1.22:5080>;tag=OBTSzyvbgcivyilvjqxe
Server: TelScale Sip Servlets 7.0.2-SNAPSHOT
Proxy-Authenticate: Digest realm="192.168.1.22",nonce="32356138316339342d353833652d343"
Content-Length: 0
]]>
</message>
Jean Deruelle provided the answer I needed:
https://github.com/Mobicents/RestComm/issues/29
A new config tag authenticate has been added to the restcomm.xml configuration file.
Set it to false to disable auth for incoming requests (REGISTER,
INVITE, MESSAGE) from SIP Clients If set to true Restcomm will
authenticate users and incoming messages from those users
true
<!-- If set to true Restcomm will authenticate users and incoming messages from those users -->
<authenticate>false</authenticate>
I am in the middle of an Authorization Code Grant Flow with Azure AD. Even though the documentation says the grant_type should be authorization_code, I am getting an error message about this property.
POST https://login.windows.net/SOME_AZURE_AD_UUID/oauth2/token?api-version=1.0
Content-Type: application/x-www-form-urlencoded
client_id=SECRET_CLIENT_ID
&client_secret=SECRET_CLIENT_SECRET
&code=SECRET_CODE
&grant_type=authorization_code
&redirect_uri=https://myserver.example.com/login/auth_return
&resource=https://myserver.example.com/
&scope=openid email
(edit: whitespace added for clarity)
The error I am getting back:
HTTP/1.1 400 Bad request
Content-Length: 436
X-Content-Type-Options: nosniff
X-Powered-By: ASP.NET
Request-Id: SOME_REQUEST_ID
X-Ms-Request-Id: SOME_REQUEST_ID
Strict-Transport-Security: max-age=31536000; includeSubDomains
Set-Cookie: x-ms-gateway-slice=slicea; path=/; secure; HttpOnly, stsservicecookie=acs; path=/; secure; HttpOnly
Server: Microsoft-IIS/8.0
Cache-Control: private
Date: Wed, 20 Aug 2014 14:44:08 GMT
Content-Type: application/json; charset=utf-8
{
"correlation_id": "SOME_CORRELATION_ID",
"error": "unsupported_grant_type",
"error_codes": [
70003
],
"error_description": "
ACS70003: The access grant 'authorization_code' is not supported.\r\n
Trace ID: SOME_TRACE_UUID\r\n
Correlation ID: SOME_CORRELATION_ID\r\n
Timestamp: 2014-08-20 14:44:08Z",
"timestamp": "2014-08-20 14:44:08Z",
"trace_id": "SOME_TRACE_UUID"
}
(whitespace added for clarity)
This request does work if I change grant_type to client_credentials (but I have not found a way to use the resulting token for what I need). It also works if I change some URLs to point to Google instead of Azure AD.
Is there a mistake with these requests or does the service genuinely not support the documented grant_type of authorization_code?
This is a bug I believe, and it took me 2-3 days to figure it out. Please do the following to get it working,
1) Remove the "?api-version=1.0" from your URL. I know it sounds strange but trust me their documentation is a mess.
2) Add a "Content-Type": "application/x-www-form-urlencoded" header in your request (hence you'll have to encode the post data values ... for example redirect_url=(encodedURL) etc
3) Remove unnecessary fields from post data REFER ... it should be like
{
'grant_type': "authorization_code",
'resource': "your resource",
'client_id': "your client Id",
'redirect_uri': "your redirect URL",
'client_secret': "your client secret",
'code': "the code u got"
}
I see you have done point 2 so you'll need to do point 1 and you're good to go.
Furthermore, if you want to get access_token quickly(if nothing I said works for you), then pass "client_credentials" in grant_type and you'll get a smaller response with access_token. But if you want the complete response with refresh_token as well, you'll have to do all those steps.
EDIT:
There is one more mistake in their documentation, for Refresh Tokens >>> the URL should be oauth2/token and NOT oauth2/authorize
Hope this helps!
try this
'grant_type':"client_credentials",
'resource': "your resource",
'client_id': "your client Id",
'redirect_uri': "your redirect URL",
'client_secret': "your client secret",