OIDC Error Handling for invalid & expired tokens

[xfh]

Describe the bug
With the old Keycloak extension, invalid or expired tokens resulted in common HTTP 401 responses. Since the refactoring of the security layer, such a request results in a HTTP 500 response:

Internal Server Error
Error handling 6ecb9992-42e1-4a79-afbd-2262dc131397-2, io.vertx.core.impl.NoStackTraceThrowable: Expired Token

A requests with e.g. an unauthorised role still results in HTTP 403 Access forbidden: role not allowed, so I am guessing the exception mapping for authentication has been forgotten.

Expected behavior
A HTTP 401 response like Unauthorised: invalid token or Unauthorised: expired token.

Actual behavior
Internal Server Error as in the screenshot bellow.

To Reproduce
Steps to reproduce the behavior:

1. Create an invalid or expired access token
2. Configure Quarkus to use the OIDC extension like in the using-openid-connect quickstart
3. Make a request with the token to a protected endpoint

Screenshots

Environment (please complete the following information):

• Output of uname -a or ver: Linux 4.19.72-gentoo
• Output of java -version: 1.8.0_202 Java HotSpot(TM) 64-Bit Server VM (build 25.202-b08, mixed mode)
• Quarkus version or git rev: 0.26.1

[stuartwdouglas]

@pedroigor @sberyozkin FYI

[xfh]

By the way: when making a request without access token, quarkus responds with HTTP 401 Not authorized

[pedroigor]

I think this is fixed by https://github.com/quarkusio/quarkus/pull/4884/files#diff-f1401467a45b52a1e0a23ca77551e4e1R36. Test here https://github.com/quarkusio/quarkus/pull/4884/files#diff-a93f781220e33322eb3e04e6fcabb961R189.

[sberyozkin]

@xfh Can you please try 0.27.0 ?

[xfh]

Ah nice, a new release. I'll try directly.

[xfh]

Now I get HTTP 403 and no error message in the log. I think it used to be 401 before, but I don't really care which one. Looks good to me.

[pedroigor]

Thanks for looking this. 401 means no bearer in the request, asking client to negotiate the token. 403 tokens either lacks permission or is invalid.

@sberyozkin another thing to consider in the guides, right ?

[sberyozkin]

@xfh re the empty log, please watch this issue.

[sberyozkin]

@pedroigor I was actually going to ask you about the statuses :-), as I thought 403 was only for the permissions related failure. I guess 401 and 403 are just used interchangeably by various OIDC adapters. If you think it is worth documenting 401 vs 403 now then sure, please, or we can wait a bit, thanks

[pedroigor]

Added a test for this scenario. See #5038.

[sberyozkin]

@pedroigor cool, thanks; 403 works as well I think

[xfh]

@pedroigor thanks for the explanation. You can close the issue.