change default provider to openid-connect

[ostempel]

Description

• changed default provider of oidc to openid-connect
• goth has here some weird naming: see here:
  https://github.com/markbates/goth/blob/15b24f54ca2944bbdb02e9be29840e3d23bcb41e/providers/openidConnect/openidConnect.go#L116C1-L122C3

And in our metal-apiserver:
https://github.com/metal-stack/metal-apiserver/blob/ae0b0ee8a5789d7012590b6cc61db445f130c073/pkg/service/auth/oidc.go#L42-L53

Problem is somehow the extraction and the fallback of goth, which uses the internal provider name and not our. It could arise in auth-service here:

	providerName, err := gothic.GetProviderName(req)

References:

• skip insecure oidc metal-apiserver#89

[majst01]

I am biased to skip this possibility to change the authentication provider. This was required in the metalstack.cloud api-server because we need to support multiple auth provider there. OTOH in metal-stack.io i doubt we need anything different than a openid-connect provider.

If we agree on this, we can also remove the suffix openid-connect from the generated tenant id.

[Gerrit91]

Why should we not provide different providers for metal-stack, too? I think it's quite likely people would like to use it at some point in the future?

[majst01]

Why should we not provide different providers for metal-stack, too? I think it's quite likely people would like to use it at some point in the future?

Because with the help of either zitadel or any other idp like keycloack, the authentication provider will stay the same

[Gerrit91]

I find these often hard to manage. I would prefer to let people decide what they want to use.

[majst01]

I find these often hard to m

But then we need to implement specific auth providers as well, which is actually not the case

[Gerrit91]

We can do it over time. Adding them is easy but as soon as the database is messed up because user IDs are not unique anymore, it's hard to fix.

[majst01]

We can do it over time. Adding them is easy but as soon as the database is messed up because user IDs are not unique anymore, it's hard to fix.

But if we force userids to be unique for example by using email (which is actually the case and enforced by masterdata-api), there is no need to splatter the userids with a meaningless suffix