-
Notifications
You must be signed in to change notification settings - Fork 32
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
Comments
We could follow the CIBA example and remove the Authorization header from examples. CIBA already states: The examples in CIBA do not mention the "Authorization" header. But CIBA already states that the request must be authenticated. 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. |
The CIBA 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. |
CIBA does require the authorization request to be authenticated but allows a wide range of methods. Removing "Basic" from the example See: camaraproject#104
@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 |
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. |
@jpengar @eric-murray @shilpa-padgaonkar The following diagram is extracted from CAMARA-AuthN-AuthZ-Concept.md under the "Client Credential Grant" section. 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: Suggest updating the documentation to mention the intended Client Credential flows and remove items which are not applicable, to achieve a common behaviour. |
Valid client authentication methods for the CIBA 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 |
#103 will delete CAMARA-AuthN-AuthZ-Concept.md |
The main objection to the example seemed to be the use of "Basic". |
@AxelNennker Understand the community will be aligned to using FAPI 2.0 Security Profile, |
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. |
@AxelNennker @mhfoo We can complete and merge PR #105 to fix this issue. |
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:
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. |
@nitroduna yes, private_key_jwt is the preferred method. |
This issue will auto close based on the successful merge of the following: |
Problem description
Referring to the following:
CIBA Backend Flow
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.
The text was updated successfully, but these errors were encountered: