Login Failed. unauthorized_client: client is not authorized

Drone Support
1

Hi there,

I’m now having issues trying to get my Drone installation to use Oauth2 using the latest gitea docker image, and using drone version drone/drone:1.3.1. I’ve created the application and callback in gitea, and created new variables in the docker image for client_id & client_secret.

When logging into drone for the first time, I’m sent to my gitea installation to accept the connection and once I’ve enabled it, I’m redirected to drone with the message of unauthorized_client.

I’ve checked forums repeatedly but not managed to get anything that works yet, Any help would be appreciated

2

I’m currently experiencing the same issue. I’ll update here if I find a solution.

I put Drone into debug mode and got these logs:

time="2019-09-18T01:50:30Z" level=debug msg="events: stream opened" request-id=1QzRRb9why2mWZxys44pdMZk7JT
time="2019-09-18T01:50:30Z" level=debug msg="events: stream error" request-id=1QzRRb9why2mWZxys44pdMZk7JT
time="2019-09-18T01:50:30Z" level=debug msg="events: stream closed" request-id=1QzRRb9why2mWZxys44pdMZk7JT
time="2019-09-18T01:50:30Z" level=debug msg="api: guest access" request-id=1QzRRb9why2mWZxys44pdMZk7JT
time="2019-09-18T01:50:30Z" level=debug fields.time="2019-09-18T01:50:30Z" latency=273.24277ms method=GET remote="<<ip>>:<<port>>" request=/api/stream request-id=1QzRRb9why2mWZxys44pdMZk7JT
time="2019-09-18T01:50:34Z" level=error msg="oauth: cannot exchange code: XP53O3IH4378GtaP_r5-ngzPYj3HcFTQdxbqwkoJGQ0=: unauthorized_client: client is not authorized"
time="2019-09-18T01:50:34Z" level=debug msg="cannot authenticate user: unauthorized_client: client is not authorized"

All of these keys and IDs and whatnot won’t be relevant by the time this is posted so I don’t view them as a security risk. That key it can’t exchange isn’t anything I’ve specified, so I’m guessing it’s something else generated during the oAuth sequence. I know Gitea has recently changed how it does some oAuth stuff. Wondering if this is a straight-up bug in Drone.

3

Have you looked at your Gitea logs to get more information?

Gitea oauth2 was contributed by a Gitea maintainer and was confirmed working back in May. There have been no changes to auth since.

cc @techknowlogick

4

Nothing useful in my Gitea logs, but I did manage to verify that the error code is coming from Gitea:

Continuing to investigate.

5

Success! It turned out that my client secret had an equals sign at the end, and the parser I was using to read it in was stripping that last equals. When the secret was passed back to Gitea, it didn’t match and I got the unauthorized_client error.

@bajmhunter Check your DRONE_GITEA_CLIENT_ID and DRONE_GITEA_CLIENT_SECRET values being passed to the Drone Docker instance. Ensure that they exactly match what’s in your Gitea control panel for the Drone application.

1 Like
6

Hi there,

I’ve had a look and seems that’s exactly whats happening on my end too. @GregJPreece how did you manage to set it to accept the equals sign at the end of the secret? Or is it easiest to regenerate until you receive one without the equals?

7

I was using a Bash script initially, to get the hang of firing Drone up, so I was utilising some pretty rudimentary parsing:

#!/bin/bash

propsfile="./drone.properties"

function prop {
    grep "${1}" ${propsfile}|cut -d'=' -f2-
}

if [ ! -f "$propsfile" ]; then
    echo "Server properties file not found"
    exit 1
fi

You can then use the props like so:

  --env=DRONE_GITEA_CLIENT_ID="$(prop 'drone.gitea.client-id')"

However, I do not think this is a good approach in the long run. Aside from from not being very Docker-y, this leaves secrets lying around in a props file that then has to be managed, and also passes them in as container env variables, which is a bit of a security issue. This was just what I was using for my initial experience. I am in the process of transferring the Bash script into a docker-compose.yml file, and handing the Gitea credentials to the Drone container via Docker Secrets. I think once I have it running, it’s likely to turn into a blog post. Perhaps @bradrydzewski would find that useful for the tutorial series they’re looking to create?

8

Thanks for that, I’ve checked but when its parsed into the docker start script its parsing successfully. I mis-understood and thought it was a parse issue when it was connecting to the gitea instance.

I currently use unRaid as my docker host, and on each one after examining the logs and boot sequences, both are loading any required parameters and variables in exactly as they should.

But for some reason, Ive just gone and built a new server and have started Gitea & Drone from scratch but still seem to get the issue. Although now I cant seem to find any major issues in the log, but still detected as an unauthorized client

Is there any way to use the old auth method, rather than the oauth2?

9

While I have no current new way to point you on debugging that, I would highly recommend staying the course with oAuth2, rather than attempting to use raw creds.

10

Not a problem, I’ll keep looking into it

Thanks for all your help so far :slight_smile: