Skip to content

TAN-8614 Omniauth vulnerability - #14728

Open
luucvanderzee wants to merge 7 commits into
masterfrom
TAN-8614-omniauth-vulnerability
Open

TAN-8614 Omniauth vulnerability#14728
luucvanderzee wants to merge 7 commits into
masterfrom
TAN-8614-omniauth-vulnerability

Conversation

@luucvanderzee

@luucvanderzee luucvanderzee commented Sep 4, 2026

Copy link
Copy Markdown
Contributor

Please read the "Summary and solution" section on the ticket for more context:

https://app.notion.com/p/govocal/Fix-omniauth-vulnerability-3ce9663b7b2680fc8a2be45b6b5042c6

Let me know if the changes in behavior are fine. If the changes in behavior will cause problems for clients, and we are sure that the affected methods return a confirmed email (even though they don't properly follow the openid spec), we can add more overrides. But in these cases it would be good if we could add a comment justifying this override, e.g. by linking to the documentation of the method itself or an explanation that we checked this with the client or something.

Changelog

Technical

  • Instead of assuming omniauth-provided email is confirmed by default: check email_verified attribute
  • Correctly document which methods always return a confirmed email

@notion-workspace

Copy link
Copy Markdown

@cl-dev-bot

cl-dev-bot commented Sep 4, 2026

Copy link
Copy Markdown
Collaborator
Messages
📖 Changelog provided 🎉
📖 Notion issue: TAN-8614
📖

Run the e2e tests

📖 Check translation progress

Generated by 🚫 dangerJS against 3ce999e

@jamesspeake jamesspeake left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Logic is sound I think, but arranging a quick catchup as I've added some comments to the ticket in terms of the methods this should affect (or not) and I think there is overlap with the ticket I was working on. Important to get this right, not only for security but to not put extra barriers in place for customers when not needed.

end

def email_always_present?
config[:provider] == 'rheinbahn'

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This logic will need to stay as keycloak covers two providers which work in slightly different ways

'name' => 'Theo Musterman',
'email' => 'Theo.Musterman@ctie.etat.lu',
'email_verified' => nil,
'email_verified' => true,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need to check the actual response here (only on staging at the moment)

expect(response).to redirect_to('/fr-FR/?param=some-param&sso_flow=signup&sso_success=true')
end

context 'when the auth response says the email is not verified' do

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would contradict confirmed_email_always_present?

Comment on lines +66 to +67
email: nil,
new_email: 'alexander@citizenlab.co',

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, if email is not confirmed it always gets created as new_email?


def email_always_present?
true
def confirmed_email_always_present?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure I'm totally getting why confirmed_email_always_present? if we still rely on email_confirmed? as well

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants