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
Copy file name to clipboardExpand all lines: README.md
+90-94Lines changed: 90 additions & 94 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -239,53 +239,109 @@ For your views you can login using:
239
239
240
240
An overview is available at https://github.com/heartcombo/devise/wiki/OmniAuth:-Overview
241
241
242
+
#### Note about multi-platform authentication (Web, Android, IOS, ...)
243
+
244
+
If you authenticate your user from multiple different platforms with a single API you will likely have different Google `client_id` depending on the platform.
245
+
246
+
This could raise errors in the callback step because the `client_id` used in the callback needs to be the same as the one used in the sign in request.
247
+
248
+
To handle multiple `client_id` you can register multiple omniauth middlewares in your devise initializer with different names and different client ids. You can then register each middleware in your omniauthable model and add a new action in your `OmniauthCallbacksController` for each additional middleware.
Google describes the One-time Code Flow [here](https://developers.google.com/identity/sign-in/web/server-side-flow). This hybrid authentication flow has significant functional and security advantages over a pure server-side or pure client-side flow. The following steps occur in this flow:
286
+
Google describes the One-time Code Flow [here](https://developers.google.com/identity/protocols/oauth2). This hybrid authentication flow has significant functional and security advantages over a pure server-side or pure client-side flow. The following steps occur in this flow:
245
287
246
-
1. The client (web browser) authenticates the user directly via Google's JS API. During this process assorted modals may be rendered by Google.
288
+
1. The client (web browser) authenticates the user directly via Google's OAuth 2 API. During this process assorted modals may be rendered by Google.
247
289
2. On successful authentication, Google returns a one-time use code, which requires the Google client secret (which is only available server-side).
248
290
3. Using a AJAX request, the code is POSTed to the Omniauth Google OAuth2 callback.
249
-
4. The Omniauth Google OAuth2 gem will validate the code via a server-side request to Google. If the code is valid, then Google will return an access token and, if this is the first time this user is authenticating against this application, a refresh token. Both of these should be stored on the server. The response to the AJAX request indicates the success or failure of this process.
291
+
4. The Omniauth Google OAuth2 gem will validate the code via a server-side request to Google. If the code is valid, then Google will return an access token and, if this is the first time this user is authenticating against this application, a refresh token. Both of these should be stored on the server. The response to the AJAX request indicates the success or failure of this process.
250
292
251
293
This flow is immune to replay attacks, and conveys no useful information to a man in the middle.
252
294
253
295
The omniauth-google-oauth2 gem supports this mode of operation when `provider_ignores_state` is set to `true`. Implementors simply need to add the appropriate JavaScript to their web page, and they can take advantage of this flow. An example JavaScript snippet follows.
254
296
255
297
```javascript
256
298
// Basic hybrid auth example following the pattern at:
redirect_uri:YOUR_REDIRECT_URI, // This redirect_uri needs to redirect to the same domain as the one where this request is made from.
310
+
response_type:'code',
311
+
scope:'email openid profile',
312
+
state:'google', // The state will be added in the redirect_uri's query params. Use can this if you use the same redirect_uri with different omniauth provider to know which one you're currently handling for example.
redirect_uri:YOUR_REDIRECT_URI, // The `redirect_uri` used in the server needs to be the same as as initially used in the client.
338
+
}),
339
+
headers: {
340
+
'Content-type':'application/json',
341
+
},
342
+
method:'POST',
287
343
});
288
-
};
344
+
}
289
345
```
290
346
291
347
#### Note about mobile clients (iOS, Android)
@@ -298,66 +354,6 @@ In that case, ensure to send an additional parameter `redirect_uri=` (empty stri
298
354
299
355
If you're making POST requests to `/auth/google_oauth2/callback` from another domain, then you need to make sure `'X-Requested-With': 'XMLHttpRequest'` header is included with your request, otherwise your server might respond with `OAuth2::Error, : Invalid Value` error.
300
356
301
-
#### Getting around the `redirect_uri_mismatch` error (See [Issue #365](https://github.com/zquestz/omniauth-google-oauth2/issues/365))
302
-
303
-
If you are struggling with a persistent `redirect_uri_mismatch`, you can instead pass the `access_token` from [`getAuthResponse`](https://developers.google.com/identity/sign-in/web/reference#googleusergetauthresponseincludeauthorizationdata) directly to the `auth/google_oauth2/callback` endpoint, like so:
0 commit comments