The following is an example password grant the service would receive.
POST /oauth/token HTTP/1.1
Host: authorization-server.com
grant_type=password
&username=user#example.com
&password=1234luggage
&client_id=xxxxxxxxxx
&client_secret=xxxxxxxxxx
I want to know , according to oAuth standard , am I allowed pass additional parameter? for instance
POST /oauth/token HTTP/1.1
Host: authorization-server.com
grant_type=password
&username=user#example.com
&password=1234luggage
&client_id=xxxxxxxxxx
&client_secret=xxxxxxxxxx
¶m1=aaaa
¶m2=bbbb
¶m3=cccc
If yes , can I have a REQUIRED additional parameter?
Sure, your Authorization Server may require an additional parameter and reject requests that don't have that. This comes at the cost of not being standards-compliant anymore and being interoperable only with Clients that have a bi-lateral agreement with you on the usage of this parameter.
Related
As per PKCE spec, OAuth provider uses code_verifier to avoid the man in the middle attack. My understanding that, it is the best alternative for JavaScript based single page application (SPA) to exchange OAuth code for token.
When I experiment this with Google API, it says "client_secret is missing".
Here is the HTTP Request and Response.
ID: 1
Address: https://oauth2.googleapis.com/token
Http-Method: POST
Content-Type: application/x-www-form-urlencoded
Headers: {Content-Type=[application/x-www-form-urlencoded], Accept=[/]}
Payload: grant_type=authorization_code&code=4%2F1AH3Ubnm550IoT8AZ_e_eqLYDn3-JyXVo22LOcAlsWPnxTV_o0tV2N1YMNFtqhvFm65n4tuZmHfK5tkKLOsbnRw&scope=openid+profile+email&redirect_uri=https%3A%2F%2Flocalhost%3A8443%2Fdemo&client_id=myclientid.apps.googleusercontent.com&code_verifier=iv8n89-Dh3QD1uroYm6e6jcpZwxff60m-RYYlmLYArun6KF8o0z%7Ee3EjyVyYUp.4XxSbyI47QQSCMrY542sLWSUnxAG8e0a%7ETjmF_UFioJMA_ctB2jz6qbcYtu9uUOKp
ID: 1
Response-Code: 400
Encoding: UTF-8
Content-Type: application/json; charset=utf-8
Headers: {Accept-Ranges=[none], Alt-Svc=[h3-28=":443"; ma=2592000,h3-27=":443"; ma=2592000,h3-25=":443"; ma=2592000,h3-T050=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q049=":443"; ma=2592000,h3-Q048=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"], Cache-Control=[private], content-type=[application/json; charset=utf-8], Date=[Mon, 22 Jun 2020 04:41:53 GMT], Server=[scaffolding on HTTPServer2], transfer-encoding=[chunked], Vary=[Origin,Accept-Encoding, Referer, X-Origin], X-Content-Type-Options=[nosniff], X-Frame-Options=[SAMEORIGIN], X-XSS-Protection=[0]}
Payload: {
"error": "invalid_request",
"error_description": "client_secret is missing."
}
Is my understanding that "we don't need client_secret when passing code_verifier" wrong or Google is not supporting PKCE or Do I miss some other parameter in the request? Please help.
I took a look and experienced the same problem when trying to use the latest Single Page App Standards. Looking at Google docs their implementation seems to still be based on the implicit flow.
I verified that you can send response_type='token id_token' and successfully get tokens, though I'd also prefer to use Authorization Code Flow (PKCE).
I tried without client_secret using keycloak on flutter app but it failed. code_verifier did not work; Hence I moved to use client_secret in my payload.
I try generate a access token in my application on WSO2 using implicit grant type, following the request:
POST /token HTTP/1.1
Host: localhost:8243
Content-Type: application/x-www-form-urlencoded
Cache-Control: no-cache
Postman-Token: d6ef6038-9860-bdc6-3867-70af98b37cc6
grant_type=code&response_type=implicit&client_id=CLIENT_ID&redirect_uri=http%3A%2F%2Flocalhost%3A8888%2Fplayground%2Foauth2client&scope=default
And the request return this error:
{
"error_description": "Invalid grant_type parameter value",
"error": "invalid_request"
}
This is my grant types settings:
Grant Types
Why this error happen, although the settings include the implicit grant type?
I think you are mixing up few things. If you want to use the Implicit grant, you don't use the /token endpoint - you get everything from the authorization endpoint. The request could look like this:
/auth?response_type=token&client_id=...&redirect_uri=...
and after a successful authentication, the client gets an access token right away as part of the redirect URL.
If you have a code and you want to exchange it for an access token and a refresh token, you are using the Authorization code grant. Then the correct grant_type value is authorization_code and you must specify the code in the code URL parameter. So the error message you are getting is correct.
Finally, the token endpoint has no response_type parameter. It's a parameter of the authrization endpoint and the correct value for the implicit flow is token, because you want an access token to be returned.
I am using OAuth 2.0 for authorization according to this documentation :(https://developers.vendhq.com/documentation/oauth.html#oauth) and having this error:
"error": "invalid_request", "error_description": "The request is missing a required parameter, includes an invalid parameter value, includes a parameter more than once, or is otherwise malformed. Check the \"grant_type\" parameter."
Request
Method : POST
Content-Type: application/x-www-form-urlencoded
URL : https://{domain_prefix}.vendhq.com/api/1.0/token
Parameters :
code = {code}
client_id = {app_id}
client_secret = {app_secret}
grant_type = authorization_code
redirect_uri = {redirect_uri}
As per the RFC6749, section 4.1.3, the encoded body of a POST request should look like code={code}&client_id={app_id}&client_secret={app_secret}&grant_type=authorization_code&redirect_uri={redirect_uri}.
Example:
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb&client_id=CLIENT_ID_1234&client_secret=CLIENT_SECRET
Do not forget to encode the redirect Uri: http://foo.bar/ => http%3A%2F%2Ffoo.bar%2F
Concerning the authentication error, it may be because the authorization server do not support client secret in post request (or your client is not allowed to use it).
Then try to add the Authorization header with basic authentication scheme.
The value of this header is Basic {ENCODED_AUTHENTICATION} with {ENCODED_AUTHENTICATION} =base64(client_id + ':' + client_secret)
With this header, the client_id and client_secret in the post request have to be removed. Your request parameters become code={code}&grant_type=authorization_code&redirect_uri={redirect_uri}.
You will need to check the URL to which you are attempting to send your POST to. The service that you are attempting to contact does not exist or is currently unavailable.
How can I locally reproduce the https GET call that my Azure Scheduler job would execute that uses Basic Authentication with a username/password?
I know I can just type in the URL in the browser to hit the action in my MVC controller, but how does Azure Scheduler send the username/password?
If Azure Scheduler uses Basic Authentication then it will send the username and password as Base64 encoded Authorization header.
The username and password are combined into a string separated by a colon, e.g.: username:password
The resulting string is encoded using the RFC2045-MIME variant of Base64, except not limited to 76 char/line.
The authorization method and a space i.e. "Basic " is then put before the encoded string.
So for example if your username=john and password=secret, the Authorization header would look like this:
Authorization: Basic am9objpzZWNyZXQ=
So you should make the following HTTP request:
GET /yourcontroller/youraction HTTP/1.1
Authorization: Basic am9objpzZWNyZXQ=
Connection: close
I have an external tool which I connected to my D2L site through LTI. When a student completes his work, I want the tool to send the grade back to the LMS.
I receive a "Not authenticated" message from D2L when sending the grade with the XML payload. How do I authenticate my grade posting?
The authentication required is down to how it must be done as described in the LTI 1.1 implementation guide. In particular (from LTI 1.1 impl guide), pay attention to section 4: LTI Security Model and section 6.1: LTI Basic Outcome Service.
Quick summary of requirements, I believe (as per section 4.3: Security for application/xml Messages):
form up the POX (plain 'ol XML) body
calculate the body hash value
set the oauth_body_hash parm to this value
sign the request as per Oauth signing rules, and note that the oauth_body_hash must be included in the base string to sign together with the other request parms
transmit the oauth_body_hash parm along with the OAuth parms in the signed request
D2L highly recommends that implementors use a reliable OAuth standard library for their particular platform to do the signature generation and verification, rather than attempt to implement the OAuth signing/verification algorithm on their own.
Note that the Oauth parms in this case get transmitted in the request header and not in the body data. The IMS spec itself contains an example of what the body should look like (sec 4.3):
POST http://www.imsglobal.org/developers/BLTI/service_handle.php HTTP/1.0
Host: 127.0.0.1:80
Content-Length: 757
Authorization: OAuth realm="",oauth_version="1.0",
oauth_nonce="29f90c047a44b2ece73d00a09364d49b",
oauth_timestamp="1313350943",oauth_consumer_key="lmsng.school.edu",
oauth_body_hash="v%2BxFnmDSHV%2Fj29qhxLwkFILrtPo%3D",
oauth_signature_method="HMAC-SHA1",
oauth_signature="8auRpRdPY2KRXUrOyz3HKCs92y8%3D"
Content-type: application/xml
<?xml version = "1.0" encoding = "UTF-8"?>
<imsx_POXEnvelopeRequest xmlns = "http://www.imsglobal.org/services/ltiv1p1/xsd/imsoms_v1p0">
<imsx_POXHeader>
<imsx_POXRequestHeaderInfo>
<imsx_version>V1.0</imsx_version>
<imsx_messageIdentifier>999999123</imsx_messageIdentifier>
</imsx_POXRequestHeaderInfo>
</imsx_POXHeader>
<imsx_POXBody>
<readResultRequest>
<resultRecord>
<sourcedGUID>
<sourcedId>3124567</sourcedId>
</sourcedGUID>
</resultRecord>
</readResultRequest>
</imsx_POXBody>
</imsx_POXEnvelopeRequest>