No API access with OAuth Client

[lukasruckenstuhl]

Describe your question/ I was trying to fetch all users from the Authentik API through the JWT method as described in the docs. https://goauthentik.io/developer-docs/api/#jwt-token

However, when I try to access the API with the access token generated, I always get a 401. What am I missing? Relevant infos Authentik Version 2024.2.1 I added the scope goauthentik.io/api to the OAuth request, but it always returns a 403 with the details 'Token invalid/expired'. In the OAuth Application/Provider configuration I haven't found the scope goauthentik.io/api, so I did not add it. (Maybe the issue is here?)

Screenshots

Logs server-1 | {"cidr":"172.16.0.0/12","event":"Setting proxy headers","level":"trace","remoteAddr":"172.19.0.1","timestamp":"2024-02-23T07:38:00Z"} server-1 | {"event":"tracing request to backend","headers":{"Accept":["/"],"Authorization":["Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6ImJjMmQyNjYwZTMyNDg4NzBlYmMwYjczOWUwYTM0YmFlIiwidHlwIjoiSldUIn0.eyJpc3MiOiJodHRwOi8vbG9jYWxob3N0OjkwMDAvYXBwbGljYXRpb24vby9wb3N0bWFuLyIsInN1YiI6ImI0YzdhN2M1ZDAyOTE5OTNjZjk2MDA1ZmM0YzU4ZjhkMDUwN2MxZTNmZWI2ZjE4Mjk2OWQ2MzE5YzI5MTA3ZGUiLCJhdWQiOiJ1bDZ6WVlFRkpSUUx1MlM2dHAySzFDSGN3am9aNURHZlRFSTdtQ0cyIiwiZXhwIjoxNzA4Njc2Mzc0LCJpYXQiOjE3MDg2NzM2NzQsImF1dGhfdGltZSI6MTcwODY3MjA1NSwiYWNyIjoiZ29hdXRoZW50aWsuaW8vcHJvdmlkZXJzL29hdXRoMi9kZWZhdWx0IiwiZW1haWwiOiJhZG1pbkBsb2NhbGhvc3QiLCJlbWFpbF92ZXJpZmllZCI6dHJ1ZSwiYXpwIjoidWw2ellZRUZKUlFMdTJTNnRwMksxQ0hjd2pvWjVER2ZURUk3bUNHMiIsInVpZCI6Im5KYVBMdTh6a1pKdFBCU3ozbXI4d1d4VFRxNE9iRGp4d2hNYXIxTEgifQ.cIzlxZCsJZv2mTaUS5txVpf7ocBoc7BuwnJVuaaZixa8QKk5R4zpflm81WCTHuUaumiKKoJ8Gu58ueUROfNidHShPIUHZ9WAug7BoBSdxjMS-N4aB9rcsC2qvvM8JkuV3xEGrGFG2r5LCbhvGdxcPpgPVa0-x9qg6xkSvwuWebX7UBtY_g0qmpB9bSDQj1eKE5nvkrpM3DgonabRygL-GB4sB847j2CBZu9jvDOKitRqXgj-gJhHUhBu5gtuQiG2i1IOKqohqwoD5vTJbXuaIGoSV5Yo1PAwlxbY8bZ623TXWOH9jNWj32PJtG_pbtRLRnPCbv6ZVLvK_JMYoZhxKjRcqFBcVMQZD5xAy9hWIBEP4nJP-VRPRhfWUDkX68TWGpnMKEwfHg3WMfFhzISqc_pfY1hq8YX0mQWlQMFVDT25YhGTm-fh8qmtjHnhQbubHaCx1omfqE5cA8QTZeJX5N-6objjNN4bhl5P2Y11oHZkZWKhq66mL9vWtZoiPWaI5bx_Wb6VVQpNUH-yd5k2sF-0ORe4GLp0HY3uqz5AQLTQnQPDHiRWMo6uDeDn_e_hILTagKptrYlWDoqtRZk3w-q2w9ifvuvkZXkNz0quo80MxtRX0Do8vnkNnNXrNYu-KqYtqPcjQv-GCd3zfqipooZVVUQbnm-zqnHg26bqylA"],"Connection":["keep-alive"],"Postman-Token":["d019704d-5c70-4670-8299-9003ae741487"],"User-Agent":["PostmanRuntime/7.36.3"]},"level":"trace","logger":"authentik.router","timestamp":"2024-02-23T07:38:00Z","url":"http://localhost:8000/api/v3/core/users/"} server-1 | {"auth_via": "unauthenticated", "domain_url": "localhost", "event": "/api/v3/core/users/", "host": "localhost:9000", "level": "info", "logger": "authentik.asgi", "method": "GET", "pid": 50, "remote": "172.19.0.1", "request_id": "ae6e9c8fb4ab42309b15f2cb2dc0f40f", "runtime": 12, "schema_name": "public", "scheme": "http", "status": 403, "timestamp": "2024-02-23T07:38:00.499548", "user": "", "user_agent": "PostmanRuntime/7.36.3"}

Version and Deployment (please complete the following information):

• authentik version: 2024.2.1
• Deployment: docker-compose

[jejbq]

Did it work with version 2023.10.7?

Maybe this is related to 2024.2.1 #8834 and authentik/crypto/apps.py

[duhast]

Same issue after upgrading from 2023.8.3 to 2024.4.2. Is there any workaround until this will be fixed?

[mhampson31]

I've had this issue too and #9910 seems to solve it for me. I think what's going on is that although the API auth process requires the 'goauthentik.io/api' scope, by default the Oauth2 provider can't be configured to grant it. (I get the sense from #9910 this wasn't necessary in the past?) So even if the client requests the scope, the token it receives doesn't have it and this query for a valid access token returns no results.

I updated to 2024.6.0-rc2, reapplied the System - OAuth2 Provider - Scopes blueprint, and then was able to add the 'goauthentik.io/api' scope to my provider. Works as expected now, for me at least.

[duhast]

Thanks for the update @mhampson31 ! I'll find time to try your approach.

[Rami-Pastrami]

I've had this issue too and #9910 seems to solve it for me. I think what's going on is that although the API auth process requires the 'goauthentik.io/api' scope, by default the Oauth2 provider can't be configured to grant it. (I get the sense from #9910 this wasn't necessary in the past?) So even if the client requests the scope, the token it receives doesn't have it and this query for a valid access token returns no results.

I updated to 2024.6.0-rc2, reapplied the System - OAuth2 Provider - Scopes blueprint, and then was able to add the 'goauthentik.io/api' scope to my provider. Works as expected now, for me at least.

I currently have Gitea setup with OpenID Connect to Authentik, and now recently have been getting "JWT token is expired" errors from Gitea. I found this github issue, and what is referenced in this issue seems like the most plausible explanation for this problem.

Your last step mentioning adding the "goauthentik.io/api" scope to the provider, can you clarify how this step is done?

Thanks!

[Rami-Pastrami]

I've had this issue too and #9910 seems to solve it for me. I think what's going on is that although the API auth process requires the 'goauthentik.io/api' scope, by default the Oauth2 provider can't be configured to grant it. (I get the sense from #9910 this wasn't necessary in the past?) So even if the client requests the scope, the token it receives doesn't have it and this query for a valid access token returns no results. I updated to 2024.6.0-rc2, reapplied the System - OAuth2 Provider - Scopes blueprint, and then was able to add the 'goauthentik.io/api' scope to my provider. Works as expected now, for me at least.

I currently have Gitea setup with OpenID Connect to Authentik, and now recently have been getting "JWT token is expired" errors from Gitea. I found this github issue, and what is referenced in this issue seems like the most plausible explanation for this problem.

Your last step mentioning adding the "goauthentik.io/api" scope to the provider, can you clarify how this step is done?

Thanks!

updating this, turns out it was due to one of the cluster servers having a unsynced clock. All is good now!

[BeryJu]

This issue was fixed with #9910 which has been released in 2024.6