Add configuration for authentication method

[NobodysNightmare]

Preparing for users to choose how they want to authenticate their nextcloud storage and if using a common IDP, what the client_id of nextcloud is.

Ticket

https://community.openproject.org/projects/cross-application-user-integration-stream/work_packages/60153

What are you trying to accomplish?

Adding configuration for the authentication method to the storage provider, so that we can work on two pieces of code afterwards:

• Building the UI that sets this configuration
• Consuming these settings to perform authentication using either method

Merge checklist

• Added/updated tests

[Kharonus]

🟡 do we need this copyright thingy here?

[mereghost]

Yes. It was, there was a discussion and all files should have it.

[Kharonus]

🟡 I think I now raise the obvious discussion: naming 🤯

I'm not a too big fan of mutual_oauth, mainly because it is not reflected anywhere in our domain speech.

suggestions:

• authorization _code_flow
• oauth2
• bidirectional_oauth2

first one is probably too specific, as oauth enables other methods, too, as client credentials (just NC is not able to do it (yet?)).

second one is my favorite, precise yet still generic enough to bring everything of this method under the hood.

For common_oidc_idp I'd probably drop the common and just go with oidc_idp.

[Kharonus]

🔥 on

[mereghost]

I'd go with oauth2 and oidc (maybe even oidc_sso).

[NobodysNightmare]

OMG, so let me put my least favorite pair first: oauth2 vs oidc 😅

I can explain: I've been thinking quite a bunch about what differentiates the two flows. And the first thing I noticed is that we shouldn't call any of the two just oauth2, because OAuth 2.0 is part of the OIDC spec. Or in other words: Everything that is OIDC is also OAuth 2.0.

Strictly speaking we don't even need the IDP to be OIDC compliant, OAuth 2.0 is mostly enough. This means we are close to oauth2 vs oauth2, which would be confusing. So what is the difference between the two strategies we want to offer?

In the beginning token_exchange would have been an acceptably good name for the new strategy, because that was a distinguishing feature and requirement. However, we later weakened the requirements to not always need OAuth 2.0 Token Exchange, by allowing to have the IDP issue tokens that work for both apps, so the name doesn't make sense anymore.

In the end, I settled for the difference being the topology of the parties. In the old strategy we have two equal parties that care about authenticating users on their own, but for the matter of cross-application calls, each one acts as OAuth 2.0 Authorization Server (AS) for the other. So when OP calls NC, then NC is the AS and when NC calls OP, then OP is the AS. The two are equal and mutually accept each other as AS.
This is different from our new strategy, where the two agree on a third party AS that hands out the tokens and both of them only need to trust that (central/common) third party. This is where I source my mutual vs common naming.

</wall-of-text>

tl;dr:

• That's why I don't like oauth2 vs oidc
• That's why I suggested mutual_oauth vs common_oidc_idp
• Iterating from @mereghost 's suggestion: I think I could accept the new strategy being called sso or oidc_sso
  • It's a bit simplified, but captures the idea pretty well still
  • But then oauth2 would still be a bad name for the other strategy... Brainstorming: two-way-oauth2? 🤔 bidi-oauth2 💭 2-oauth2 🤯

[NobodysNightmare]

P.S.:

mainly because it is not reflected anywhere in our domain speech

I totally intend to take whatever we decide on and make it part of our domain speech.

[mereghost]

I'd go with oauth2 and oidc (maybe even oidc_sso).