Difference between revisions of "Authentication Cookie"
From MgmtWiki
(→Problems) |
(→Problems) |
||
(One intermediate revision by the same user not shown) | |||
Line 3: | Line 3: | ||
==Context== | ==Context== | ||
− | [[Cookies]] were introduced to [[Web Site]]s to enable a continuity of the user experience. One of the most difficult parts of the user experience was to create a | + | [[Cookies]] were introduced to [[Web Site]]s to enable a continuity of the user experience. One of the most difficult parts of the user experience was to create a [[Single Sign-On]] (SSO) experience to avoid pestering the user with too many [[Authentication]] interruptions. |
==Problems== | ==Problems== | ||
*The use of [[Cookies]] on various devices and [[User Agent]]s has be restricted in ever more severe ways. These restrictions have limited the functionality of the [[Authentication Cookie]]. | *The use of [[Cookies]] on various devices and [[User Agent]]s has be restricted in ever more severe ways. These restrictions have limited the functionality of the [[Authentication Cookie]]. | ||
− | *In particular Apple introduced a restriction on | + | *In particular Apple introduced a restriction on [[SameSite]] cookies that caused common implementations of [[OAuth 2.0]] and [[OpenID Connect]] to fail. Brock Allen has decoded that issue on his site<ref>Brock Allen, ''Same-site cookies, ASP.NET Core, and external authentication providers.'' (2019-01-11) https://brockallen.com/2019/01/11/same-site-cookies-asp-net-core-and-external-authentication-providers/</ref> The basic problem with OAuth front channel [[Authentication]] is determining which site is the [[SameSite]]. So, while the authentication works, the redirect to the client code is not considered, by iOS 12, to be a same-site operation. Even in the case a refresh of the client site will work and be fully authenticated, because it is not a redirect, but a [[SameSite]] operation. |
==Solution== | ==Solution== |
Revision as of 10:45, 8 May 2021
Full Title or Meme
An Authentication Cookie is a compact collection of data provided to a User Agent by a Web Site to be retrieved later as proof that an Authentication has be successful with this session on this device.
Context
Cookies were introduced to Web Sites to enable a continuity of the user experience. One of the most difficult parts of the user experience was to create a Single Sign-On (SSO) experience to avoid pestering the user with too many Authentication interruptions.
Problems
- The use of Cookies on various devices and User Agents has be restricted in ever more severe ways. These restrictions have limited the functionality of the Authentication Cookie.
- In particular Apple introduced a restriction on SameSite cookies that caused common implementations of OAuth 2.0 and OpenID Connect to fail. Brock Allen has decoded that issue on his site[1] The basic problem with OAuth front channel Authentication is determining which site is the SameSite. So, while the authentication works, the redirect to the client code is not considered, by iOS 12, to be a same-site operation. Even in the case a refresh of the client site will work and be fully authenticated, because it is not a redirect, but a SameSite operation.
Solution
As User Agents get more careful about the handling of same-site operations, the Web Site needs to be more careful about how redirects are handled.
Reverences
- ↑ Brock Allen, Same-site cookies, ASP.NET Core, and external authentication providers. (2019-01-11) https://brockallen.com/2019/01/11/same-site-cookies-asp-net-core-and-external-authentication-providers/