AWSのApplication Load Balancerの認証機能を使って、スタッフからのアクセスのみ許可する社内向けウェブサービスを運用しているのだけど、昨日くらいからGoogle Chromeで認証が通らなないという声を聞くようになった。
現象としてはリダイレクトループが発生していて、コンソールを見るとSet-Cookie headerが長すぎるというエラーが出ていた。
Set-Cookie header is ignored in response from url: https://****/oauth2/idpresponse?code=e51b4cf0-8b8e-495f-8db0-3bb0039dfed4&state=****. Cookie length should be less than or equal to 4096 characters
問題の起きたタイミングでデプロイしたわけでもないので、ブラウザの都合かAWSの都合かな、と思って調べたところ、フォーラムに同じ現象に遭遇している書き込みがあった。
When using ALB authentication, the default session cookie name (AWSELBAuthSessionCookie) and Chromium 80, the ALB attempts to set cookies which are too long (greater than 4096 characters). This causes the browser to reject the cookies and authentication to fail.
Use Case #4 from this post (https://forums.aws.amazon.com/ann.jspa?annID=7413) says:
"To ensure customers are backwards compatible after the Chromium update, ALB will parse the user-agent header to determine if a client is using a version of Chromium 80 or greater and set ‘SameSite=None’ attribute if they are."The length of an ALB session cookie with the default name is usually at most 4092 characters. Using Chromium 80 it is 4106, with the 14 extra characters coming from "SameSite=None;". This seems like an ALB bug.
The workaround is to set a shorter session cookie name (9 characters or less).
https://forums.aws.amazon.com/thread.jspa?messageID=932968&tstart=0
- 2020年2月のALBのアップデートで、ALBがChromium 80以降のUser-AgentならSameSite=Noneを付与するようになった
- そのさいcookie headerの文字数が上限を超えてしまうことがある
- cookie nameを9文字以下に縮めるワークアラウンドがある
- デフォルトのCookie名はAWSELBAuthSessionCookie
問題の起きていた社内サービスでは、cookie nameを9文字以下に縮めたところ無事ログインできるようになった。
CloudFormationのドキュメントはこのあたり。
一方で、ほぼ同じ構成で動かしている別のサービスではcookieの長さが700バイトくらいで済んでいるものもあり、再現条件は分かっていない。
