Implement OAuth2 authorization flow (retrieve/revoke token)

[MazeXP]

This PR implements only the OAuth2 specific endpoints that make sense to be called by an application:

• Retrieve token: oauth/token
• Revoke token: oauth/token/revoke

The oauth/authorize endpoint is not to be called by an application but been opened by an actual user.
Therefore we could provide some builder for those URLs.

Related issues

#210 (Missing mentioned builder for authorize URLs)

[Nihlus]

While this looks perfectly fine, I'm somewhat concerned about the scope leakage of adding OAuth support like this. These structures and endpoints are not defined by Discord, but rather follows the application-independent RFC 6749 definition of OAuth flows.

This is especially problematic since the error format of these endpoints does not follow Discord's structures, and as such we'd be left with arcane exceptions if an OAuth call fails.

There are multiple existing libraries that handle this in an integrated fashion, and I'm not sure this is something Remora should handle. I'd like some discussion from the community before deciding one way or another, though.

[Hamsterland]

Not all OAuth implementations are the same. The API I am working with now for example does not support scopes or revoking tokens and has its own custom parameter for authentication. Discord’s is also slightly specialised. Therefore, I strongly believe this should remain in the library. There are no other OAuth packages in the Remora ecosystem. And I remember that when the lack of the OAuth API in Remora.Discord was brought up, there were more than a few of us who expected it to be here but were surprised that it wasn’t.

[MazeXP]

I totally understand the point of Nihlus. As he is completely right that the OAuth definition is actually independent of Discord.
But I think all the existing OAuth client solutions have a hard dependency on OWIN and focus on the complete OAuth2 flow.
That means they do not support revoking the actual token. (e.g. on flogout the token should be revoked)
We could also just put it into its own discord independent project.

@Hamsterland
I suppose you mean code_verifier, code_challenge and code_challenge_method?
If yes, then those are also part of the OAuth definition under the name of PKCE. [RFC]
Discord does actually also support PKCE, but they have not mentioned it in their docs. It was only mentioned by night in an issue.

[AraHaan]

I am personally indecisive if this is actually needed or not. For me personally I see no value in using it in my current discord bot however.

[MazeXP]

The use case would mostly be desktop applications that allow users to authenticate using Discord.

[Nihlus]

Based on this, I think it's reasonable we include it in Remora.Discord, then. However, the PR will need more work to properly handle OAuth error responses (probably by registering a new HttpClient just for these operations) and any additional considerations resulting from supporting what is ostensibly a different API surface than the Discord one.

[MazeXP]

I would actually suggest then to have it in its own project not related to Discord:
Remora.Reat.OAuth2

Therefore it could be a lightweight generalized implementation of the OAuth2 specs.

[Hamsterland]

I think I agree with @MazeXP. The main concern here is that no other Auth library is part of the Remora ecosystem.

[Nihlus]

I'll close this PR, then, and start putting together an OAuth library.

[MazeXP]

Alright, if you need a hand just hit me up.
Got quite some knowledge on OAuth2