When "urn:ietf:wg:oauth:2.0:oob" is used as a redirect URI, redirect to
an internal dex page where the user is shown the code and instructed to
paste it into their app.
* validation of client moved into its own method and tested
* public clients have different validation - must have no redirect URIs
and must have a clientName set
The proposal templates was not intended to be show for every issue,
only for proposal. Revert that issue template and add more general
one in a follow up commit.
This reverts commit 09cb38577f.
API Driver is dead: This API turns out to not be super useful, requiring
an existing client to create other clients is weird.
Long live API Driver? Let's use Dynamic Client API and the bootstrap API
to create a better API Driver! LONG LIVE API DRIVER.
The only thing using this AFAIK is dexctl in api_driver mode, which
no-one uses - it's a sort of weird API which requires a client to create
other clients, and gives all clients the ability to list all other
clients. So we are removing it.
Before, this logic was only in the OIDCServer.CodeToken() method; now it has been
pulled out so that other paths, like OIDCServer.RefreshToken() can use
it.
The net affect, is that now refresh tokens can be used to get
cross-client authenticated ID Tokens.
A refresh request must fail if it asks for scopes that were not
originally granted when the refresh token was obtained.
This Commit:
* changes repo to store scopes with tokens
* changes repo interface signatures so that scopes can be stored and
verified
* updates dependent code to pass along scopes
Github launched the ability to automatically populate issues and pull requests with custom templates automatically
(https://github.com/blog/2111-issue-and-pull-request-templates). This eliminates the need to have custom scripts
for populating github issues with custom templates. It should be easier for contributors to just open an issue
and not worrying about copy the template.
Checking that trusted peers exist means that you have to create clients
in a certain order, or else create all the clients, then update trusted
peers. Either way, not a great experience during setup.
The downside, of course, is that you lose validation of peer
IDs.
The Client object on its own doesn't fully express everything about a
single client, and so when loading clients from a static configuration
it's not enough to just (de)serialize clients.
To that end, LoadableClient contains the full representation of a client
and associated entities.
Replaced by ClientRepoFromClients, which makes more sense IMO. Also, it
was doing the wrong thing: it was ignoring the client_id and client_secret
passed into it as far as I can tell.
