Difference between revisions of "Authentication Cookie"
From MgmtWiki
(Created page with "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 su...") |
(→Other Materiel) |
||
| (12 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| + | ==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. | 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 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== | ||
| + | *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 [[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== | ||
| + | As [[User Agent]]s get more careful about the handling of same-site operations, the [[Web Site]] needs to be more careful about how redirects are handled. | ||
| + | ===Redirects=== | ||
| + | According to this blog post: http://blog.dubbelboer.com/2012/11/25/302-cookie.html all major browsers, IE (6, 7, 8, 9, 10), FF (17), Safari (6.0.2), Opera (12.11) both on Windows and Mac, set cookies on redirects. This is true for both 301 and 302 redirects. | ||
| + | |||
| + | ==Reverences== | ||
| + | <references /> | ||
| + | ===Other Materiel=== | ||
| + | * See the wiki page on [[Cookies]] | ||
| + | |||
| + | [[Category:Glossary]] | ||
| + | [[Category:Authentication]] | ||
Latest revision as of 14:21, 21 December 2021
Contents
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.
Redirects
According to this blog post: http://blog.dubbelboer.com/2012/11/25/302-cookie.html all major browsers, IE (6, 7, 8, 9, 10), FF (17), Safari (6.0.2), Opera (12.11) both on Windows and Mac, set cookies on redirects. This is true for both 301 and 302 redirects.
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/
Other Materiel
- See the wiki page on Cookies
