Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alignment of Client Credential authentication / authorization using API Gateway Pattern #104

Closed
mhfoo opened this issue Dec 26, 2023 · 15 comments · Fixed by #121
Closed
Labels
correction API specification needs correction

Comments

@mhfoo
Copy link
Collaborator

mhfoo commented Dec 26, 2023

Problem description
Referring to the following:
CIBA Backend Flow

POST /bc-authorize HTTP/1.1
Authorization: Basic {Credentials}
Content-Type: application/x-www-form-urlencoded

login_hint=tel%3A%2B346xxyyyzzz&
… 

The authorization should follow API Gateway Pattern with Client Credential Grant access token usage, instead of Basic authentication.

Expected behavior
Align with API Gateway Pattern mentioned above.

Alternative solution
N.A.

Additional context
GSMA has a concept of a north star where the API consumer authentication / authorization is the same implementation for all Operator Open Gateway CIBA implementation and only a change in credentials is sufficient for a change in API provider.

@mhfoo mhfoo added the correction API specification needs correction label Dec 26, 2023
@AxelNennker
Copy link
Collaborator

We could follow the CIBA example and remove the Authorization header from examples.
That is what I suggest.

CIBA already states:
"Because in the CIBA flow, the OP does not have an interaction with the end-user through the consumption device, it is REQUIRED that the Client provides one (and only one) of the hints specified above in the authentication request, that is "login_hint_token", "id_token_hint" or "login_hint". "

The examples in CIBA do not mention the "Authorization" header.

But CIBA already states that the request must be authenticated.
"The Client MUST authenticate to the Backchannel Authentication Endpoint using the authentication method registered for its client_id, such as the authentication methods from Section 9 of [OpenID.Core] or authentication methods defined by extension in other specifications"

So, even when the Authorization header is not present in examples it is clear that the authorization request must be authenticated. It could also be a signed request.
https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html#signed_auth_request

@eric-murray
Copy link
Collaborator

The CIBA bc-authorize example is just that - an example. I assume client_secret_basic authentication was used as that is the default, but it is not mandated. Discussions on OpenID Connect profiles for CAMARA have not really started, but I'd expect private_key_jwt to be the preferred option. This is the example given in the CIBA specification, and is also used in the GSMA OGW reference implementation.

Requesting a bearer token to allow you to submit a subsequent request for another bearer token seems unnecessarily convoluted, and will not help latency at all.

AxelNennker added a commit to AxelNennker/IdentityAndConsentManagement that referenced this issue Jan 4, 2024
CIBA does require the authorization request to be authenticated but allows a wide range of methods.

Removing "Basic" from the example

See: camaraproject#104
@mhfoo
Copy link
Collaborator Author

mhfoo commented Jan 15, 2024

@jpengar mentioned the following client credentials in the 12 Jan, Open Gateway Weekly Technical Drop In Sessions (GitHub) meeting.

https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication

related to Open Gateway Issue 97

@jpengar
Copy link
Collaborator

jpengar commented Jan 15, 2024

Just to avoid naming misunderstandings. The link I shared is what the OpenID Connect core specification defines for Client Authentication. Consider the client role definition per OAuth 2.0 - RFC6749. The client is generally an application that makes protected resource requests on behalf of and with the permission of the resource owner.
And usually when we talk about "Client Credentials" we are referring to Client Credentials authorization grant.

@mhfoo
Copy link
Collaborator Author

mhfoo commented Jan 18, 2024

@jpengar @eric-murray @shilpa-padgaonkar

The following diagram is extracted from CAMARA-AuthN-AuthZ-Concept.md under the "Client Credential Grant" section.

cc

In the above diagram, the "Authorization Server" and "Resource Service" aka CAMARA Service are protected by the API Gateway. The diagram illustrates the "Token request" and "Token Usage" flow and the involved components.

Question:
Should the CIBA endpoint "POST /bc-authorize" be protected following the above "Token request" and "Token Usage" flows and API Gateway?

Suggest updating the documentation to mention the intended Client Credential flows and remove items which are not applicable, to achieve a common behaviour.

@eric-murray
Copy link
Collaborator

@mhfoo

Valid client authentication methods for the CIBA /bc-authorize endpoint are discussed here:

The Client MUST authenticate to the Backchannel Authentication Endpoint using the authentication method registered for its client_id, such as the authentication methods from Section 9 of [OpenID.Core] or authentication methods defined by extension in other specifications.

So basically, anything goes. CAMARA have not yet specified which method(s) are allowed, but the GSMA OGW reference implementation uses private_key_jwt.

@mhfoo
Copy link
Collaborator Author

mhfoo commented Jan 19, 2024

#103 will delete CAMARA-AuthN-AuthZ-Concept.md

@AxelNennker
Copy link
Collaborator

The main objection to the example seemed to be the use of "Basic".
I suggest to either replace "Basic" by some other method or leave the Authorization header value blank, indicating that the heaser is needed but the example does not provide a value.

@mhfoo
Copy link
Collaborator Author

mhfoo commented Jan 23, 2024

The main objection to the example seemed to be the use of "Basic". I suggest to either replace "Basic" by some other method or leave the Authorization header value blank, indicating that the heaser is needed but the example does not provide a value.

@AxelNennker
Yes, using "Basic" is a security concern.

Understand the community will be aligned to using FAPI 2.0 Security Profile, private_key_jwt with jwks_uri
Telefónica will contribute their version as a starting point.

@mhfoo
Copy link
Collaborator Author

mhfoo commented Jan 25, 2024

IdentityAndConsentManagement PR 113

Will answer this question

@jpengar
Copy link
Collaborator

jpengar commented Jan 30, 2024

IdentityAndConsentManagement PR 113

Will answer this question

@mhfoo Then, if it's okay with you, I suggest to close this issue. Just make sure you review PR #113 to verify that the OIDC profile being defined is aligned with Signtel's expectations and needs.

@jpengar
Copy link
Collaborator

jpengar commented Jan 30, 2024

The main objection to the example seemed to be the use of "Basic". I suggest to either replace "Basic" by some other method or leave the Authorization header value blank, indicating that the header is needed but the example does not provide a value.

@AxelNennker @mhfoo We can complete and merge PR #105 to fix this issue.

@nitroduna
Copy link

I don't know if this is already resolved, but just to clarify. The bc-authorize endpoint has to validate the client_id (APP) credentials. As the spec says this have to be done using the same methods used in another OAuth2 endpoints that require client_id (APP) credentials, such as the token endpoint.

So any of these methods are available:

  • Authorization header with Basic auth including the "client_id:client_secret" encoded in Base64
  • Using private_key_jwt method, which is done with the parameter "client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer" and the parameter "client_assertion" with the signed JWT assertion.

Both systems are valid to any protected OAuth2 endpoint and therefore valid for bc-authorize endpoint.

I think that in CAMARA, the "private_key_jwt" authentication is the method selected for any auth endpoint that requires APP authentication or credentials. If that so, the bc-authorize should use the same authentication method.

@mhfoo
Copy link
Collaborator Author

mhfoo commented Feb 6, 2024

@nitroduna yes, private_key_jwt is the preferred method.

@mhfoo
Copy link
Collaborator Author

mhfoo commented Feb 7, 2024

IdentityAndConsentManagement PR 113
Will answer this question

@mhfoo Then, if it's okay with you, I suggest to close this issue. Just make sure you review PR #113 to verify that the OIDC profile being defined is aligned with Signtel's expectations and needs.

@jpengar

This issue will auto close based on the successful merge of the following:
#105 and #113 😀

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
correction API specification needs correction
Projects
None yet
6 participants