Redirect to the only oAuth2 provider when other login methods are disabled

[navneet102]

Fixes: #36846

Summary

• Redirect to the single available OAuth2 provider when the /login route is accessed if other login methods are disabled in the configuration
• Avoids rendering the login page unnecessarily when there's only one authentication option available
• Added skipAutoLogin URL parameter to bypass the auto-redirect feature by using ?skipAutoLogin=true escape hatch (useful when the auth source is temporarily unavailable)

Changes

File	Change
routers/web/auth/auth.go	Implemented performAutoLoginOAuth2 to handle redirection and updated SignIn to trigger it when password, OpenID, Passkey, and SSPI login methods are disabled.
routers/web/auth/auth_test.go	Added SignInAutoRedirectSingleProvider unit test to verify automatic redirection and the skipAutoLogin bypass.

Test plan

• Manual testing with a single OAuth2 provider configured as the only login method
• Verify redirect happens automatically on /login
• Verify ?skipAutoLogin=true bypasses the redirect
• Verify redirect to ?redirect_to= happens after authentication

Assisted by Claude Code

[wxiaoguang]

• Added skipAutoLogin URL param to bypass this feature by including ?skipAutoLogin=true

What will it be used for? Who will use it? Any real world use case for it?

If it is not used by our code, not clearly documented for real world use cases, then it doesn't make sense.

[navneet102]

I included it because it was mentioned in this comment, it could be used if auth source is unavailable.

What do you suggest, should I?

1. Document it.
2. Remove it.

[navneet102]

@wxiaoguang I have added some tests. Could you check this now please?

[wxiaoguang]

• Added skipAutoLogin URL param to bypass this feature by including ?skipAutoLogin=true

What will it be used for? Who will use it? Any real world use case for it?

If it is not used by our code, not clearly documented for real world use cases, then it doesn't make sense.

I included it because it was mentioned in this comment, it could be used if auth source is unavailable.

What do you suggest, should I?

1. Document it.

2. Remove it.

I don't understand it

[navneet102]

Sorry for being vague.

• Added skipAutoLogin URL param to bypass this feature by including ?skipAutoLogin=true

What will it be used for? Who will use it? Any real world use case for it?

If it is not used by our code, not clearly documented for real world use cases, then it doesn't make sense.

I think you asked here about why I included the skipAutoLogin URL parameter if there was no documentation for it.

In the reply, I mentioned that it was a design choice specified by @silverwind while accepting the feature proposal in this issue's (#36846 ) discussion.

What do you suggest, should I?

1. Document it.
2. Remove it.

Here I asked you, if I should remove the skipAutoLogin URL param or should I add documentation for it.

[wxiaoguang]

What do you suggest, should I?

1. Document it.
2. Remove it.

Here I asked you, if I should remove the skipAutoLogin URL param or should I add documentation for it.

As I said, I don't understand it.

You are the author so you need to propose reasonable and feasible designs.

[wxiaoguang]

You can explain your design by answering the questions:

1. For "Document it": why it is useful, in which case it will be used, how end users can know how to use it.
   • "useful when the auth source is temporarily unavailable": you already have !EnablePasswordSignInForm check, so users can do nothing on the login page even if the auth source is unavailable
   • I don't think such reason makes sense.
2. For "Remove it": why the extra parameter is useless, why the suggestion from silverwind (If there is just 1 login provider configured, redirect to it #36846 (comment)) is not right.