Answer token endpoint failures with the RFC 6749 error codes, and look up the UserInfo client by azp

[longsleep]

Two fixes in how the token and UserInfo endpoints identify the client and report failures.

Token endpoint error codes

The token endpoint answered two kinds of failure with error codes RFC 6749 section 5.2 does not assign to them. What a client does next depends on the code, so it took the wrong action.

• A refresh token which is malformed, expired or signed with a key lico does not hold was answered with invalid_request. It now answers invalid_grant, which tells the client to sign in again rather than to fix its request.
• A failed client lookup, for an unknown client_id or a wrong secret alike, was answered with access_denied, which belongs to the authorization endpoint. It now answers invalid_client. oidc-go does not define that code, so it is added in oidc/errors.go.
• A client which authenticated with the Authorization header gets invalid_client with status 401 and WWW-Authenticate: Basic realm="<issuer>", as section 5.2 asks. Credentials sent in the body keep the 400.

This matters most for pre-registered, long-lived clients: they outlive refresh tokens and key rotations, and a mistyped secret is how an operator usually meets invalid_client.

UserInfo client lookup

UserInfo took the client from the first aud value. Since #273, a token bound to a resource carries the resource as aud and the client in azp. For such a token:

• the registration lookup missed, so a client registered with userinfo_signed_response_alg got unsigned JSON;
• the identity backend was told that the resource was the client.

UserInfo now uses azp when present, as every other lookup of a client by token already does.

Tests and docs

• TestTokenRefresh gains an expired and a malformed refresh token, both expecting invalid_grant.
• The new TestTokenClientAuthentication covers an unknown client and a wrong secret, each sent in the body and in the header.
• TestAuthorizeAndTokenWithResource gains a subtest expecting signed user info for a resource-bound token. Without the fix it gets unsigned JSON.
• The API spec documents which failures answer invalid_grant and which invalid_client, the 401, and the UserInfo behaviour.