Introduction to Cookie-Based OAuth:
Cookie based authentication means a record or session is kept on both server and client after successful authentication. The server needs to keep track of active sessions in a database, while on the front-end a cookie is created that holds a session identifier, thus the name cookie based authentication. Let's look at the flow of traditional cookie based authentication:
- User enters their login credentials
- Server verifies the credentials are correct and creates a session which is then stored in a database
- A cookie with the session ID is placed in the users browser
- On subsequent requests, the session ID is verified against the database and if valid the request processed
- Once a user logs out of the app, the session is destroyed both client and server side
An Example for a response Cookie after a successful authentication on login.yahoo.com; as you can see below, the cookie can used for all yahoo services :
B | |
value | 1l8ho6dcegkd7&b=4&d=HgwMCNFpYF…-&s=kv&i=TfHDcO9y6mkFjxWhbDE. |
expires | 2018-11-03T06:32:49.000Z |
path | / |
domain | .yahoo.com |
T | |
value | z=UT2.ZBUndDaB11GHg8F6v1gNDA3T…yaHBJWFBFaERieGxOeFdoa0lfQS0t |
expires | 2018-11-03T06:32:49.000Z |
path | / |
domain | .yahoo.com |
secure | true |
httpOnly | true |
F | |
value | d=4sMy6fw9vKe3LupImzVW8xbvD5PbG.m91X5ZiQ-- |
expires | 2018-11-03T06:32:49.000Z |
path | / |
domain | .yahoo.com |
httpOnly | true |
PH | |
value | fn=bBgBMfijDlxXi2dUxA--&l=en-US&i=us |
expires | 2018-11-03T06:32:49.000Z |
path | / |
domain | .yahoo.com |
Y | |
value | v=1&n=419s8uji31kdh&l=o57dc2wd…000000&r=12p&lg=en-US&intl=us |
expires | 2018-11-03T06:32:49.000Z |
path | / |
domain | .yahoo.com |
FS | |
value | v=1&d=qMCywpyeSiwyltwPKbJsSe6u…6frYY1reKF_HUHX9sdQRx_IOA--~A |
expires | 2019-11-03T18:32:50.000Z |
path | / |
domain | .login.yahoo.com |
secure | true |
httpOnly | true |
SSL | |
value | v=1&s=dCB_5fIO7vnoBJf11mpwNKhH…8PLsurfECue_nC2Go3zbTkIgBg-~A |
expires | 2018-11-03T06:32:49.000Z |
domain | .yahoo.com |
path | / |
secure | true |
httpOnly | true |
AO | |
value | u=1 |
expires | 2037-11-02T14:47:31.000Z |
path | / |
domain | .yahoo.com |
AS | |
value | v=1&s=nUSq8Ryl&d=A59fcb5f6|5P5…iuftrKF5INgcpkhM.X_8R8X1PU-~A |
path | / |
domain | login.yahoo.com |
secure | true |
httpOnly | true |
Once I click on the Mail icon (mail.yahoo.com) for example, the following cookie is attached to my request , the same cookie I received in response to my authentication on login.yahoo.com
B | 1l8ho6dcegkd7&b=4&d=HgwMCNFpYF…-&s=kv&i=TfHDcO9y6mkFjxWhbDE. |
T | z=UT2.ZBUndDaB11GHg8F6v1gNDA3T…yaHBJWFBFaERieGxOeFdoa0lfQS0t |
F | d=4sMy6fw9vKe3LupImzVW8xbvD5PbG.m91X5ZiQ-- |
PH | fn=bBgBMfijDlxXi2dUxA--&l=en-US&i=us |
Y | v=1&n=419s8uji31kdh&l=o57dc2wd…000000&r=12p&lg=en-US&intl=us |
SSL | v=1&s=dCB_5fIO7vnoBJf11mpwNKhH…8PLsurfECue_nC2Go3zbTkIgBg-~A |
AO | u=1 |
How does this relate to Isolation?
Short Answer: You must configure the proxy forwarding policy to isolate both login.yahoo.com and mail.yahoo.com or Both Search Engines/Portals and Email if you match using URL categories, for the user to be able to open his Email account.
Long Answer:
If you have a use case where the proxy is configured to forward only Email Category to FG, and this Email service delegates authentication to OAuth Portal (Example; you request mail.yahoo.com, you are redirected to login.yahoo.com for authentication) , the user will fail to open his Email Account and redirection keeps happening even if the user is successfully authenticated, why? because login.yahoo.com (as an example for an OAuth portal) is not isolated, which means the response cookie is saved on the user machine , while the mail.yahoo.com is sent from the isolation VM which has no cookies!
Isolating both Search Engines/Portals (login.yahoo.com & accounts.google.com) and Email (mail.yahoo.com and mail.google.com) is required