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

API Design - Error Handling should include RFC6749 exception #129

Closed
laughingbiscuit opened this issue Feb 2, 2024 · 4 comments
Closed
Labels
documentation Improvements or additions to documentation

Comments

@laughingbiscuit
Copy link

Problem description

The API Design Guidelines discuss the standardized error format.

{
   "status": 400,
   "code": "INVALID_ARGUMENT",
   "message": "A human readable description of what the event represent"
}

This makes sense for most APIs, except existing OAuth APIs such as when obtaining client_credentials access token. There are already errors defined for this in the format here:

{
  "error":"xxx",
  "error_description": "xxx",
  "error_uri": "xxx"
}

Expected action

Documentation should indicate which format takes priority.

@laughingbiscuit laughingbiscuit added the documentation Improvements or additions to documentation label Feb 2, 2024
@eric-murray
Copy link
Collaborator

The API design guidelines only apply to the service APIs. The standards and profiles that apply to the authentication flow itself are being discussed within the Identity & Consent working group. The already standardised error response will apply unless changes are agreed by that working group.

@rartych
Copy link
Collaborator

rartych commented Feb 13, 2024

@jpengar Could you get some insights/views from Identity & Consent subproject how to resolve this issue? More specific problem is also presented also in #128.

@AxelNennker
Copy link
Contributor

AxelNennker commented Feb 13, 2024

@rartych As per your request I commented on the original issue #128 (comment)

Which is about what OIDC and OAuth2 define as error responses for their endpoints.

The document https://github.com/camaraproject/Commonalities/blob/main/documentation/API-design-guidelines.md#6-error-responses talks about resource server responses which are not standardized by OIDC nor OAuth2.
So, Camara can recommend/define what ever Camara wants without violating OIDF or IETF standards.

I think there is no contradiction here and the issue can be closed, but maybe I am missing the point.

@jpengar
Copy link
Collaborator

jpengar commented Feb 13, 2024

I agree with Axel.
On the one hand we have the AuthZ/AuthN process to get an access_token to access CAMARA Service APIs. The authorization flows agreed in CAMARA follow the OpenID connect/OAuth standards. So the error format will be the one defined by those standards for the Authorize Request and the Token Request.
On the other hand, we have CAMARA NBI interface to consume Service APIs, i.e. API client uses obtained access_token to consume the target CAMARA API for which the access_token was obtained. The API design guidelines, and especially in this case the defined error format, only apply to the invocation of service APIs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

5 participants