Login issues when switching and refreshing login page on multiple tabs

By: Mathieu Minh user 12 Dec 2018 at 2:51 p.m. CST

2 Responses
Mathieu Minh gravatar
Hi Gluu team, I would like to build a strong login cinematic with SSO. Considering the `APP_A` and `APP_B` **User Case 1 : Standard login flow** 1. Open a tab in a browser 2. Go to : https://APP_A 3. Redirection to : https://acme/oxauth/login.htm 4. Authentication by login / password 5. Redirection to : https://APP_A/home 6. Open an other tab 7. Go to : https://APP_B 8. Redirection to : https://APP_B/home **=> OK** **Use Case 2 : Login by switching and refreshing tabs on the login page** 1. Open a tab in a browser 2. Go to : https://APP_A 3. Redirection to : https://acme/oxauth/login.htm 4. Open an other tab 5. Go to : https://APP_B 6. Redirection to : https://acme/oxauth/login.htm 7. Click on the tab of APP_A 8. Authentication by login / password 9. `Redirection to : https://APP_B/home` 10. Click on tab of the APP_B and Refresh the page 11. `no redirection (always on https://acme/oxauth/login.htm) and the login form disapeared` **=> KO** In my understanding, * after login from the tab of APP_A (step 9) I should have been redirected to https://APP_A/home * and on refresh of the tab of APP_B (step 11) I should have been redirected to https://APP_B/home Is there a way to implement my need ? Thanks in advance for your help. Regards, Mathieu
CentOS 7.0
closed

Answers

By Michael Schwartz Account Admin 12 Dec 2018 at 3:54 p.m. CST

Copy
Michael Schwartz gravatar
The redirect_uri is sent in the authentication request. It's ok to have multiple redirect_uri's. Make sure your OpenID Connect client application sends the right redirect_uri.

By Mathieu Minh user 23 Dec 2018 at 10:30 a.m. CST

Copy
Mathieu Minh gravatar
Hi Michael, After further investigations and verifications, my clients are well configured. Here is the requests sent by the clients : **TAB 1 / APP_A** ``` GET /oxauth/restv1/authorize?client_id=@!1D4B.BAB2.ED4C.7336!0001!0639.266D!0008!CE3F.E0B2.9630.53AE&duration=permanent&redirect_uri=https://192.168.1.14:8443/login&response_type=code&scope=openid+user_name+email+permission+clientinfo&state=K6Iq8A HTTP/1.1 Host: acme Connection: keep-alive Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8 Accept-Encoding: gzip, deflate, br Accept-Language: fr-FR,fr;q=0.9,en-US;q=0.8,en;q=0.7 Cookie: org.gluu.i18n.Locale=en; session_id=97120130-e44c-4f77-80d9-12b09a024fc8; session_state=f8a17bae-54f8-4d1b-b097-41c303c40cc1 GET /oxauth/authorize.htm?scope=openid+user_name+email+permission+clientinfo&response_type=code&redirect_uri=https%3A%2F%2F192.168.1.14%3A8443%2Flogin&state=K6Iq8A&client_id=%40%211D4B.BAB2.ED4C.7336%210001%210639.266D%210008%21CE3F.E0B2.9630.53AE HTTP/1.1 Host: acme Connection: keep-alive Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8 Accept-Encoding: gzip, deflate, br Accept-Language: fr-FR,fr;q=0.9,en-US;q=0.8,en;q=0.7 Cookie: org.gluu.i18n.Locale=en; session_id=97120130-e44c-4f77-80d9-12b09a024fc8; session_state=f8a17bae-54f8-4d1b-b097-41c303c40cc1 ``` **TAB 2 / APP_B** ``` GET /oxauth/restv1/authorize?client_id=@!1D4B.BAB2.ED4C.7336!0001!0639.266D!0008!AD60.D45A.9A20.0DA9&duration=permanent&redirect_uri=https://192.168.1.14:8444/login&response_type=code&scope=openid+user_name+email+permission+clientinfo&state=hbqly2 HTTP/1.1 Host: acme Connection: keep-alive Cache-Control: max-age=0 Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8 Accept-Encoding: gzip, deflate, br Accept-Language: fr-FR,fr;q=0.9,en-US;q=0.8,en;q=0.7 Cookie: org.gluu.i18n.Locale=en; session_id=6d62e266-9b1a-42d3-b4aa-688b1ee3bdf9; session_state=8b2eb9ec-c305-4b8f-a72d-fd54601a18ae GET /oxauth/authorize.htm?scope=openid+user_name+email+permission+clientinfo&response_type=code&redirect_uri=https%3A%2F%2F192.168.1.14%3A8444%2Flogin&state=hbqly2&client_id=%40%211D4B.BAB2.ED4C.7336%210001%210639.266D%210008%21AD60.D45A.9A20.0DA9 HTTP/1.1 Host: acme Connection: keep-alive Cache-Control: max-age=0 Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8 Accept-Encoding: gzip, deflate, br Accept-Language: fr-FR,fr;q=0.9,en-US;q=0.8,en;q=0.7 Cookie: org.gluu.i18n.Locale=en; session_id=6d62e266-9b1a-42d3-b4aa-688b1ee3bdf9; session_state=8b2eb9ec-c305-4b8f-a72d-fd54601a18ae ``` Furthermore, for each application the authentication flow works with the good redirection. for both applications the diplayed page is https://acme/oxauth/login.htm This page manages 3 cookies : * i18n.Locale * session_id * session_state It seems that the `/authorize` parameters are stored in the `AuthorizeAction.java` and shared in the same browser session by using the session_id and session_state cookies : ``` @RequestScoped @Named public class AuthorizeAction // OAuth 2.0 request parameters private String scope; private String responseType; private String clientId; private String redirectUri; private String state; ``` So when multiple applications in different tabs but same browser session call the `/authorize` endpoint, the last call win with its client configuration and for each login page displayed, the redirection will be the last `redirectUri`. Is there a way to handle this (query parameters ....) and preserve the context of each login page? Regards, Mathieu

Post an answer