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.

Sign up for GitHub

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

RFC: API Auth Flow for Applications #63

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

RFC: API Auth Flow for Applications #63

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 32 additions & 0 deletions 063-api-auth/proposal.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,32 @@
# Summary

We want to look into having a supported and documented Concourse API. The main purpose for this API amongst users will be to utilize it within
their own applications. To be able to do this, users need access to tokens that last for an indefinite length. Currently, this doesn't exist within Concourse
Copy link

@aoldershaw aoldershaw Jun 24, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With OAuth2, applications typically request tokens using the client_credentials grant type, where clients are registered with a client ID and client secret on configuring Concourse (or more accurately, Dex). They can then request tokens using the client ID and secret to authenticate. These tokens don't live indefinitely, but they shouldn't need to - the application can just request a new token periodically.

In fact, it looks like we even have some support for clients with client_credentials - https://github.com/concourse/concourse/blob/4875181f0a5818419fe1bbae5f48eaf33515ff90/skymarshal/skycmd/flags.go#L50

@jwntrs will have a better idea of what's needed to get this to work (if anything). Also please correct me if anything I said was wrong Josh, not 100% sure about this stuff.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aoldershaw yup thats exactly right.

We actually already expose clients to end users:
https://github.com/concourse/concourse/blob/6451bfe5ffd72d0ac53314d57669a43598018a5c/skymarshal/skycmd/flags.go#L50

And they get passed directly to dex: https://github.com/concourse/concourse/blob/6451bfe5ffd72d0ac53314d57669a43598018a5c/atc/atccmd/command.go#L1655

The problem is the token won't be authorized to do anything, because it doesn't map to any teams. Right now we only look at users and groups in a way that is very specific to dex:
https://github.com/concourse/concourse/blob/cedbc290b62d60cdd7fdc240bdb3752acda02497/atc/api/accessor/accessor.go#L133-L163

So we would need to modify the set-team command to let you authorize the token. Right now fly set-team takes in very specialized values like --github-user so that we can do some magical claim mapping. What we probably want is a much more free form fly set-team command that lets you pass in arbitrary claim value pairs. Something along the lines of fly set-team --claim sub --value f064bd520bd45065ee238d5b283fa4e2. Down the road this would let people user any auth provider they want because we won't be relying on the custom structure of dex tokens.

Hopefully this helps, let me know if you want more details.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We actually already do this free form claim mapping for system requests:
https://github.com/concourse/concourse/blob/cedbc290b62d60cdd7fdc240bdb3752acda02497/atc/atccmd/command.go#L247-L248

as tokens expire within 24hrs. For users that are currently using the undocumented API this means that they have to continually log back in, which is a pain.

# Proposal

Our thought is that we can add this token via the CLI as a command like `fly generate-token`. This would be an indefinite token that would be able to be revoked at
any time. The token would grant access to the current read api endpoints.

```
$ fly -t ci generate-token
token saved to file
```
The token can then be used by an application to send requests to the API.

# Open Questions

- How would these tokens be revoked if they become compromised. Perhaps they're stored in the database and can be removed?
- Who has access to generate tokens? Do we just grant access to admins?
- Should we grant access to every read API endpoint or just a selection?
- How does a user define the selection when generating the token?
- Are tokens team scoped?


# Answered Questions


# New Implications

- Should not change any existing workflows, but it should create a path forward for new ones.