Let's assume that your website allows users to upload or create content, and that a hacker has found a vulnerability and is exploiting that at domainownedbyme.com/~hacker/.

The hacker has also created a lookalike of your website at domainnotownedbyme.com. There they have copied your OIDC login form and your client id.

The hacker changes the login flow at their site to "implicit flow" or "hybrid flow" which doesn't require the client secret.

The hacker changes the redirect_uri in their login form to domainownedbyme.com/~hacker/, which of course is a match to domainownedbyme.com/* and will be accepted by the OIDC server.

The page at domainownedbyme.com/~hacker/ redirects the user to domainnotownedbyme.com/welcome, where e.g. the user is tricked into thinking that they are logged in.

Also, since we're now using the implicit or hybrid flow, the user's identity has already been revealed, so the hacker has at least some information about the user, e.g. the email address.

After that, the hacker can e.g. claim that the user's password has expired and must be changed. The user may not reflect on the fact that they logged in using OIDC, and will enter one of their "standard passwords", which could even be the same as for their email account.

Attacks usually stack phishing, vulnerabilities and misconfigurations on top of each other to achieve very impressive feats. The above is nothing in comparison.

Also, attacks can have a fail rate of over 99% and still be successful if they fool at least some people.

Let's assume that your website allows users to upload or create content, and that a hacker has found a vulnerability and is exploiting that at domainownedbyme.com/~hacker/.

The hacker has also created a lookalike of your website at domainnotownedbyme.com. There they have copied your OIDC login form and your client id.

The hacker changes the login flow at their site to "implicit flow" or "hybrid flow" which doesn't require the client secret.

The hacker changes the redirect_uri in their login form to domainownedbyme.com/~hacker/, which of course is a match to domainownedbyme.com/* and will be accepted by the OIDC server.

When a user is tricked into logging in at domainnotownedbyme.com, they are redirected from the OIDC server to domainownedbyme.com/~hacker/, which in turn redirects the user to domainnotownedbyme.com/welcome, which pretends that the user has really logged into your website.

Since we're now using the implicit or hybrid flow, the user's identity has already been sent from the OIDC server, so the hacker has at least some information about the user, e.g. the email address.

After that, the hacker can e.g. claim that the user's password has expired and must be changed. The user may not reflect on the fact that they logged in using OIDC, and will enter one of their "standard passwords", which could even be the same as for their email account.

Attacks usually stack phishing, vulnerabilities and misconfigurations on top of each other to achieve very impressive feats. The above is nothing in comparison.

Also, attacks can have a fail rate of over 99% and still be successful if they fool at least some people.

Let's assume that your website allows users to upload or create content, and that a hacker has found a vulnerability and is exploiting that at domainownedbyme.com/~hacker/.

The hacker has also created a lookalike of your website at domainnotownedbyme.com. There they have copied your OIDC login form and your client id.

The hacker changes the login flow at their site to "implicit flow" or "hybrid flow" which doesn't require the client secret.

The hacker changes the redirect_uri in their login form to domainownedbyme.com/~hacker/, which of course is a match to domainownedbyme.com/* and will be accepted by the OIDC server.

The page at domainownedbyme.com/~hacker/ redirects the user to domainnotownedbyme.com/welcome, where e.g. the user is tricked into thinking that they are logged in.

Also, since we're now using the implicit or hybrid flow, the user's identity has already been revealed, so the hacker has at least some information about the user, e.g. the email address.

After that, the hacker can e.g. claim that the user's password has expired and must be changed. The user may not reflect on the fact that they logged in using OIDC, and will enter one of their "standard passwords", which could even be the same as for their email account.

Attacks usually stack phishing, vulnerabilities and misconfigurations on top of each other to achieve very impressive feats. The above is nothing in comparison.

Also, attacks can have a fail rate of over 99% and still be successful if they fool at least some people.

It's not reasonable for developers to predict all possible combinations of vulnerabilities, so we should assume the worst.

Never use "I have no idea how an attacker could ..." as an argument for that your system is secure.

Let's assume that your website allows users to upload or create content, and that a hacker has found a vulnerability and is exploiting that at domainownedbyme.com/~hacker/.

The hacker has also created a lookalike of your website at domainnotownedbyme.com. There they have copied your OIDC login form and your client id.

The hacker changes the login flow at their site to "implicit flow" or "hybrid flow" which doesn't require the client secret.

The hacker changes the redirect_uri in their login form to domainownedbyme.com/~hacker/, which of course is a match to domainownedbyme.com/* and will be accepted by the OIDC server.

The page at domainownedbyme.com/~hacker/ redirects the user to domainnotownedbyme.com/welcome, where e.g. the user is tricked into thinking that they are logged in.

Also, since we're now using the implicit or hybrid flow, the user's identity has already been revealed, so the hacker has at least some information about the user, e.g. the email address.

After that, the hacker can e.g. claim that the user's password has expired and must be changed. The user may not reflect on the fact that they logged in using OIDC, and will enter one of their "standard passwords", which could even be the same as for their email account.

Attacks usually stack phishing, vulnerabilities and misconfigurations on top of each other to achieve very impressive feats. The above is nothing in comparison.

Also, attacks can have a fail rate of over 99% and still be successful if they fool at least some people.