Skip to content
This repository was archived by the owner on Jul 18, 2025. It is now read-only.

Conversation

@dmcgowan
Copy link
Contributor

The auth response will return an identity token from a login when long lived token authentication is supported. The identity token can be used in the auth config in place of basic authentication to get registry access tokens.

See distribution/distribution#1418 for further context on supporting long lived oauth tokens.

@MHBauer
Copy link
Contributor

MHBauer commented Feb 23, 2016

Why identitytoken on one and IdentityToken on the other? (Capitalization differences)

The auth response will return an identity token from a login when long lived token authentication is supported.
The identity token can be used in the auth config in place of basic authentication to get registry access tokens.

Signed-off-by: Derek McGowan <derek@mcgstyle.net> (github: dmcgowan)
@dmcgowan dmcgowan force-pushed the registry-token-auth branch from 98afac4 to 7b3e5c8 Compare February 23, 2016 23:50
@dmcgowan
Copy link
Contributor Author

@MHBauer trying to be consistently inconsistent. Not sure why the responses use CamelCase and the auth type doesn't but I would rather match the case of the field structs.

@calavera
Copy link
Contributor

LGTM although I'd rather wait until we have a PR in docker/docker to handle this before merging it.

@dmcgowan
Copy link
Contributor Author

@calavera I have no problem waiting to merge

@dmcgowan
Copy link
Contributor Author

dmcgowan commented Mar 4, 2016

We are ready to open up a PR on docker/docker now that distribution/distribution#1475 has been merged.

@aaronlehmann
Copy link

LGTM

@calavera: Are you okay with merging this now, with the Docker Engine PR coming later today? Then the engine PR will be able to vendor a real engine-api update instead of a fake one.

calavera added a commit that referenced this pull request Mar 4, 2016
Add support for getting token from login
@calavera calavera merged commit 7ceade0 into docker-archive-public:master Mar 4, 2016
@calavera
Copy link
Contributor

calavera commented Mar 4, 2016

Merged! 🎉

@aaronlehmann
Copy link

@calavera: Thanks!


// IdentityToken is used to authenticate the user and get
// an access token for the registry.
IdentityToken string `json:"identitytoken,omitempty"`
Copy link

Choose a reason for hiding this comment

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

Sorry I'm late to this party, but I do feel that @calavera comment in moby/moby#20970 (comment) does seem to make sense. Do we need a new field if IdentityToken and Password are mutually exclusive? I wouldn't fight for it much if there's a nice benefit in doing it this way. Thanks!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

They are mutually exclusive but either way a field would be required in order to differentiate the secret type. For storage of the auth config I think it is fine to combine the "secret" information into a single field which could be the focus of protection, but at this point in the code having a fully enumerated structure is in my opinion the better design.

Copy link

Choose a reason for hiding this comment

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

Thanks @aaronlehmann for clarifying for me: Password is sent with basic auth, but IdentityToken goes over Authorization: Bearer ..., so the client does need to know which one it is dealing with.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants