Adopt Authorization Code Grant

[jgaehring]

See https://www.drupal.org/project/farm/issues/3185721#comment-13960019

@paul121, @mstenta and I just discussed this in a call and I think this is something we can postpone for now, b/c the security concern @paul121 raised in that d.o issue can be easily remedied without forcing Field Kit to switch over to Authorization Code Grant. That is, we can keep using the Password Credentials Grant, even while adding a redirect url for farm_client's Authorization Code. We could do so indefinitely, but I think it makes sense to adopt Authorization Codes and redirects from a UX perspective, whenever we get a chance.

[jgaehring]

Quick followup on one other potential issue @mstenta raised with redirects:

What url would we give as the redirect_uri for the Cordova builds?

I was trying to remember the bit we did to finally resolve #324:

https://github.com/farmOS/farmOS-client/blob/684f19efbd3a0399292f0c3cf1cbafd1edaa2570/config.xml#L27-L28

Basically, the config above makes our domain app://localhost/, at least for the iOS build, so presumably our redirect_uri would need to be something like that.

But no telling for sure until we actually try it out. Which is all the more reason to punt.

[paul121]

Just did a quick search, a couple good resources for implementing this in native apps:

• https://tools.ietf.org/html/rfc8252#section-4.1 (It's actually explained quite well in the spec, even includes a diagram!)
• https://auth0.com/blog/oauth-2-best-practices-for-native-apps/
• https://www.oauth.com/oauth2-servers/oauth-native-apps/checklist-server-support-native-apps/

The authorization server must permit at least three redirect URI options for the response sent back to the native app:

Private-Use URI Scheme Redirection
Claimed "https" Scheme URI Redirection
Loopback Interface Redirection

Regarding the redirect_uri... app://localhost seems like it would be valid!

But yes, this seems like something we can punt on for now. It shouldn't be awfully hard to incorporate the authorization flow later on 👍

---

FWIW... perhaps most important here is that an embedded user-agent (like web-view) is NOT used. An external user-agent (like a browser) should be used instead: https://tools.ietf.org/html/rfc8252#section-8.12

Section 9 of OAuth 2.0 [RFC6749] documents two approaches for native
apps to interact with the authorization endpoint. This best current
practice requires that native apps MUST NOT use embedded user-agents
to perform authorization requests and allows that authorization
endpoints MAY take steps to detect and block authorization requests
in embedded user-agents. The security considerations for these
requirements are detailed herein.

Embedded user-agents are an alternative method for authorizing native
apps. These embedded user-agents are unsafe for use by third parties
to the authorization server by definition, as the app that hosts the
embedded user-agent can access the user's full authentication
credential, not just the OAuth authorization grant that was intended
for the app.

In farmOS 1.x I think it's possible to register multiple redirect_uri per client. But it doesn't seem like this is the case for 2.x. For this reason, we might need to create two clients: farm_client and farm_client_native, so that each has its own redirect_uri. An added benefit of two clients is that users' access history would be separated between two clients as well, and tokens could be revoked independently. Just some added granularity.