Hi Sue.
That error can come back for a number of reasons. The following might help.
Its important to note that authentication using BA can be achieved in one of two ways:
1. Using the reverse proxy to assert BA and it provide the client identity via the iv-user header. This will mean that only BA can be used to authenticate to the endpoint. This pattern is described at
this KC page2. Using the authentication implemented at the delegate to perform authentication. This is likely what you're using as it allows authentication via post-parameter as well as through other methods like a JWT.
If you're using option 2. I'd suggest the following checks on the web reverse proxy:
1. Asserting the acl attached to /token - it should be
isam_oauth_unauth2. That the junction is set to
-b ignore mode, so that its not filtering the Authorization header from reaching the backend.
If both of these are set, the next step would be to check the messages.log or enabling trace and checking the logfile to see if theres any further information being logged as to why the request is failing. In some instances that message is used for errors not related to authentication which might result in the 400 not a 401. The trace string you can use is
com.tivoli.am.fim.oauth20.*=ALL
Hope this helps
Leo
------------------------------
Leo Farrell
------------------------------
Original Message:
Sent: Mon September 13, 2021 10:21 AM
From: Sue BAYLISS
Subject: OAuth 2.0 /token request with invalid basicAuth client credentials received 400 instead of 401
I've configured an API definition and client for OAuth 2.0 client_credentials grant type and request an access token using the /token endpoint.
If I send valid client ID and client secret in either basicAuth "Authorization" HTTP header or in request body parameters client_id & client_secret, request completes successfully HTTP response code 200 and response body contains the access token.
But I also want to test the error case where the client ID is unknown or the client secret is invalid:
- From the OAuth 2.0 specification rfc6749 "5.2 Error Response" says "The authorization server responds with an HTTP 400 (Bad Request) status code (unless specified otherwise) and includes the following parameters with the response:" ... "invalid_client: Client authentication failed (e.g., unknown client, no client authentication included, or unsupported authentication method). The authorization server MAY return an HTTP 401 (Unauthorized) status code to indicate which HTTP authentication schemes are supported. If the client attempted to authenticate via the "Authorization" request header field, the authorization server MUST respond with an HTTP 401 (Unauthorized) status code and include the "WWW-Authenticate" response header field matching the authentication scheme used by the client."
- So I expected the 401 response when unknown client or invalid client secret are send via the "Authorization" header, but my token requests always fail with 400 (Bad Request) and
{ "error_description": "FBTOAU204E An invalid client assertion or client secret was provided for the client identifier.", "error": "invalid_client" }
I've tried with WRP stanza ba-auth = both, or ba-auth=none (to allow runtime to perform authentication).
Is it possible to configure IBM Secure Verify Access to return the 401 as described above (and 400 if invalid client ID/client secret are sent as request body parameters)?
Thanks, Sue
------------------------------
Sue Bayliss
------------------------------