Incorrect handling for denied authorization attempts

[ThisIsMissEm]

In OAuth, you can receive a request to the redirect_uri with the parameter error, this can happen for a variety of reasons, but the most common one is "the user has denied access", in this case the error parameter will be set to access_denied

I believe it's a case of adding in logic like:

			let error = callbackURL.queryItems?.first(where: { $0.name == "error" })?.value
			if let error = error {
				switch error.lowercased() {
				case "access_denied":
					throw AuthenticatorError.accessDenied
				default:
					// We do actually have error and error_description parameters, so
					// could create a more specific error than missingAuthorizationCode
					throw AuthenticatorError.missingAuthorizationCode
				}
			}

Likely to the performUserAuthentication(manual: Bool, userAuthenticator: UserAuthenticator) method, after it has invoked userAuthenticator.

At present, the error you get is just the AuthenticatorError.missingAuthorizationCode raised in, for example, the Bluesky service, due to missing parameters (code, iss, or state).

[mattmassicotte]

Ah, ok I did not know this!

And yes your suggested fix seems 100% reasonable to me.

[ThisIsMissEm]

@mattmassicotte here's what the Error Response looks like for authorization: https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-09.html#section-4.1.2.1

We still get state, iss, but also error which is all these:

[ThisIsMissEm]

Maybe it'd be possible to transform the query params into a known Struct?

[ThisIsMissEm]

Okay, I've tackled this in #56, it is a stacked PR, just because the code churn is quite high between the open PRs.