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
The API adopts similar URL format as the standard OAuth2. Additional metadata about how to handle the request is communicated through the `state` parameter as a JSON string.
122
+
121
123
### Authentication OAuth 2.0
122
124
123
-
The OAuth2 flow for the shim starts after a web application sends a client out to a providers site to grant permissions. The response is an authorization code "[AUTH_CODE]" which is returned to your site, this needs to be exchanged for an Access Token. Your page then needs to send this code to an //auth-server with your client_id in exhchange for an access token, e.g.
125
+
[STATE] includes:
126
+
127
+
||key||value||
128
+
|oauth.version|2|
129
+
|oauth.grant|[PROVIDERS_OAUTH2_GRANT_URL]|
130
+
131
+
132
+
The OAuth2 flow for the shim starts after a web application sends a client out to a providers site to grant permissions. The response is an authorization code "[AUTH_CODE]" which is returned to your site, this needs to be exchanged for an Access Token. Your page then needs to send this code to an //auth-server to be exhchanged for an access token, e.g.
124
133
125
134
126
135
?redirect_uri=[REDIRECT_PATH]
127
136
&code=[AUTH_CODE]
128
137
&client_id=[APP_KEY]
129
138
&state=[STATE]
130
-
&grant_url=[PROVIDERS_OAUTH2_GRANT_URL]
131
139
132
-
133
-
The client will be redirected back to the location of [REDIRECT_PATH], with the contents of the server response as well as whatever was defined in the [STATE] in the hash. e.g...
140
+
The //auth-server exchanges the Authorization code for an access_token and redirects the client back to the location of [REDIRECT_PATH], with the contents of the server response as well as whatever was defined in the [STATE] in the hash. e.g...
@@ -139,18 +146,24 @@ The client will be redirected back to the location of [REDIRECT_PATH], with the
139
146
140
147
### Authentication OAuth 1.0 & 1.0a
141
148
149
+
[STATE] includes:
150
+
151
+
||key||value||
152
+
|oauth.version|1.0a|
153
+
|oauth.request|[OAUTH_REQUEST_TOKEN_URL]|
154
+
|oauth.auth|[OAUTH_AUTHORIZATION_URL]|
155
+
|oauth.token|[OAUTH_TOKEN_URL]|
156
+
|oauth_proxy|//auth-server|
157
+
142
158
OAuth 1.0 has a number of steps so forgive the verbosity here. An app is required to make an initial request to the //auth-server, which in-turn initiates the authentication flow.
143
159
144
160
145
-
?redirect_uri=[REDIRECT_PATH]
161
+
//auth-server?redirect_uri=[REDIRECT_PATH]
146
162
&client_id=[APP_KEY]
147
-
&request_url=[OAUTH_REQUEST_TOKEN_URL]
148
-
&auth_url=[OAUTH_AUTHORIZATION_URL]
149
-
&token_url=[OAUTH_TOKEN_URL]
150
163
&state=[STATE]
151
164
152
165
153
-
The OAuthShim signs the client request and redirects the user to the providers login page defined by `[OAUTH_AUTHRIZATION_URL]`.
166
+
The //auth-server signs the client request and redirects the user to the providers login page defined by `[OAUTH_AUTHRIZATION_URL]`.
154
167
155
168
Once the user has signed in they are redirected back to a page on the developers app defined by `[REDIRECT_PATH]`.
156
169
@@ -159,20 +172,17 @@ The provider should have included an oauth_callback parameter which was defined
The page you defined locally as the `[REDIRECT_PATH]`, must then construct a call to //auth-server to exchange the unauthorized oauth_token for an access token. This would look like this...
169
180
170
181
171
-
?oauth_token=abc12465
182
+
//auth-server?oauth_token=abc12465
172
183
&redirect_uri=[REDIRECT_PATH]
173
184
&client_id=[APP_KEY]
174
185
&state=[STATE]
175
-
&token_url=[OAUTH_TOKEN_URL]
176
186
177
187
178
188
Finally the //auth-server returns the access_token to your redirect path and its the responsibility of your script to store this in the client in order to make subsequent API calls.
0 commit comments