You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently on v0.32.0 the supported grant types on the auth tab are client credentials and password credentials.
Would it be possible to add support for authorization code?
An example of the authorization flow could be found here.
It would require some extra fields from the ones that are currently available on the auth tab to configure the endpoints, the state and the code verifier.
For example on postman:
There are 2 authorization code ways, with PKCE, which requires the code_verification to be generated, and the one without.
The one without PKCE is faster, it requires sending a GET request to the authorize endpoint without the need to generate the code verifier to get the "code" parameter to get the token later:
GET http://example.com/oauth/authorize
?client_id=3f407a5d-071a-4af3-90f0-e6604057c21a
&redirect_uri=https://example.com/callback/uri
&scope=openid
&response_type=code
&state=pifycdr62al
This will return a 30x status code response that appends the "code" query param to the "redirect_uri" url (callback url) we specified after the user logs in. This will be found on the "location" header of the response.
Then to actually get the token we call the token generation one (access token url) using the value of the "code" query param we just obtained:
POST http://example.com/oauth/token
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&
code=Nx4J0D&
client_id=3f407a5d-071a-4af3-90f0-e6604057c21a&
client_secret={clientSecret}&
redirect_uri=https://example.com/callback/uri
If we use PKCE the first request would change a bit, since we'd need to calculate a cryptographically random string using the characters A-Z, a-z, 0-9, and the punctuation characters -._~ (hyphen, period, underscore, and tilde), between 43 and 128 characters long.
We'd then use it to generate the code verifier using SHA256 (otherwise the same verifier string is used) in base64 for the code challenge parameter.
So we end up with something like:
GET http://example.com/oauth/authorize
?client_id=3f407a5d-071a-4af3-90f0-e6604057c21a
&redirect_uri=https://example.com/callback/uri
&scope=openid
&response_type=code
&code_challenge_method=S256
&code_challenge=tbMbWsmc28wih6PblLGgZmlsXRsW3Jpw8nG6uBijGVw
&state=pifycdr62al
To get the token we'd just add the code_verifier we randomly generated before:
POST http://example.com/oauth/token
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&
code=Nx4J0D&
client_id=3f407a5d-071a-4af3-90f0-e6604057c21a&
client_secret={clientSecret}&
code_verifier=T8E1nmftLDfiVfz750DxXraSA2TEguj7IcP1YKl5Ych
redirect_uri=https://example.com/callback/uri
The text was updated successfully, but these errors were encountered:
Currently on v0.32.0 the supported grant types on the auth tab are client credentials and password credentials.
Would it be possible to add support for authorization code?
An example of the authorization flow could be found here.
It would require some extra fields from the ones that are currently available on the auth tab to configure the endpoints, the state and the code verifier.
For example on postman:
There are 2 authorization code ways, with PKCE, which requires the code_verification to be generated, and the one without.
A site to test this type of authorization here.
The one without PKCE is faster, it requires sending a GET request to the authorize endpoint without the need to generate the code verifier to get the "code" parameter to get the token later:
This will return a 30x status code response that appends the "code" query param to the "redirect_uri" url (callback url) we specified after the user logs in. This will be found on the "location" header of the response.
Then to actually get the token we call the token generation one (access token url) using the value of the "code" query param we just obtained:
... which should return something like:
If we use PKCE the first request would change a bit, since we'd need to calculate a cryptographically random string using the characters A-Z, a-z, 0-9, and the punctuation characters -._~ (hyphen, period, underscore, and tilde), between 43 and 128 characters long.
We'd then use it to generate the code verifier using SHA256 (otherwise the same verifier string is used) in base64 for the code challenge parameter.
So we end up with something like:
To get the token we'd just add the code_verifier we randomly generated before:
The text was updated successfully, but these errors were encountered: