{"action":"created","issue":{"url":"https://api.github.com/repos/coreos/dex/issues/467","repository_url":"https://api.github.com/repos/coreos/dex","labels_url":"https://api.github.com/repos/coreos/dex/issues/467/labels{/name}","comments_url":"https://api.github.com/repos/coreos/dex/issues/467/comments","events_url":"https://api.github.com/repos/coreos/dex/issues/467/events","html_url":"https://github.com/coreos/dex/issues/467","id":160304700,"number":467,"title":"Prep Work for native clients.","user":{"login":"bobbyrullo","id":9629,"avatar_url":"https://avatars.githubusercontent.com/u/9629?v=3","gravatar_id":"","url":"https://api.github.com/users/bobbyrullo","html_url":"https://github.com/bobbyrullo","followers_url":"https://api.github.com/users/bobbyrullo/followers","following_url":"https://api.github.com/users/bobbyrullo/following{/other_user}","gists_url":"https://api.github.com/users/bobbyrullo/gists{/gist_id}","starred_url":"https://api.github.com/users/bobbyrullo/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bobbyrullo/subscriptions","organizations_url":"https://api.github.com/users/bobbyrullo/orgs","repos_url":"https://api.github.com/users/bobbyrullo/repos","events_url":"https://api.github.com/users/bobbyrullo/events{/privacy}","received_events_url":"https://api.github.com/users/bobbyrullo/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2016-06-14T23:06:59Z","updated_at":"2016-06-15T00:16:18Z","closed_at":null,"body":"## Intro\r\n\r\n\"Native clients\" are soon to be introduced. These clients have essentially public IDs and Secrets, and there are some APIs for which the ID/Secret pair can be used to gain credentials. I wasn't sure what these were, so I made a survey of all the known APIs (except the Admin(bootstrap) APIs and OIDC apis)\r\n\r\n## Authn Types\r\n\r\nAuthn: clientTokenMiddleware\r\nImpl: server/auth_middleware.go\r\nDesc: JWT with client as both sub and aud as bearer token (obtained from token endpoint)\r\nNotes: a bit annoying in that a user has to go to /token using client creds, to obtain these creds, then hit the endpoint they want to hit.\r\n\r\nAuthn: userJWT\r\nImpl: server/user.go::getCreds()\r\nDesc: JWT obtained from authenticating to a client sub=user, aud=client\r\n\r\n## APIS from schema/workerschema\r\n\r\nResource: Clients\r\nDesc: lists, creates OIDC clients\r\nImplementation: server/client\\_resource.go\r\nAuthn: clientTokenMiddleware\r\nAuthz: \r\nUsed: cmd/dexctl/driver_api.go - the dexctl driver NewClient command\r\nNotes: This is used for existing clients to create other clients...not sure if this is really so useful.\r\nProposal: drop. One day soon create new dextcl driver which uses admin api and admin token\r\n\r\nResource: Users\r\nDesc: User Management API: List, Get, Create, Disable, ResendEmailInvite\r\nImplementation: biz logic: user/api/api.go http: server/user.go\r\nAuthn: userJWT \r\nAuthz: user has to be Admin, client has to be admin\r\nUsed: console.\r\nNotes: \r\nProposal: keep.\r\n\r\nResource: RefreshClient\r\nDesc: List, Revoke refresh tokens for a user.\r\nImplementation: biz logic: user/api/api.go http: server/user.go\r\nAuthn: userJWT\r\nAuthz: can only see, mutate tokens for self.\r\nUsed: nowhere yet - should be in console, maybe dexctl.\r\nNotes: \r\nProposal: Keep, but maybe should be in a seperate place from user mgmt server.\r\n\r\n## Other APIS, endpoints\r\n\r\nAPI: resendEmail\r\nDesc: resends email\r\nImplementation: server/email_verification\r\nAuthn: clientTokenMiddleware + user JWT\r\nAuthz: verifies emailResend Token\r\nUsed: console, tectonic.com presumably.\r\nNotes: \r\nProposal: Keep. Disallow for native clients?\r\n\r\nAPI: sendResetPassowrd\r\nImplementation: \r\nAuthn: session key\r\nUsed: from within Dex UI\r\nProposal: keep\r\n\r\nAPI: resetPassword\r\nAuthn: resetPasswordToken \r\nUsed: within dex, part of password reset flow\r\nProposal: keep\r\n\r\nAPI: invitationAccept\r\nImplementation: \r\nAuthn: invation token\r\nProposal: keep\r\n\r\nAPI: clientRegistration (OIDC Spec dynamic reg)\r\nImplementation: server/client_registration\r\nAuthn: None\r\nProposal: Keep\r\n\r\n## summary\r\n\r\nWe don't want people native client creds to be able to be able initiate email resends, or to create, list all clients.\r\n\r\nIn fact, we probably don't want just anyone with a client to be able to list all other clients or create clients. So I propose the following:\r\n\r\n1) get rid of driver_api.go - yes, we want to dexctl to use APIs...but not these APIs. As far as I kow no one is using dexctl in this mode\r\n\r\n2) get rid of client_resource apis - no one except api\\_driver  was using them, and no one is using that\r\n\r\n3) when implementing native client, special case the /token endpoint to never give out GrantTypeClientCreds for native clients\r\n\r\n4) in the future when we implement methods in the worker api for udpating client metdata by clients use an \"registration access token\" rather than client_id/secret pairs"},"comment":{"url":"https://api.github.com/repos/coreos/dex/issues/comments/226054345","html_url":"https://github.com/coreos/dex/issues/467#issuecomment-226054345","issue_url":"https://api.github.com/repos/coreos/dex/issues/467","id":226054345,"user":{"login":"ericchiang","id":2342749,"avatar_url":"https://avatars.githubusercontent.com/u/2342749?v=3","gravatar_id":"","url":"https://api.github.com/users/ericchiang","html_url":"https://github.com/ericchiang","followers_url":"https://api.github.com/users/ericchiang/followers","following_url":"https://api.github.com/users/ericchiang/following{/other_user}","gists_url":"https://api.github.com/users/ericchiang/gists{/gist_id}","starred_url":"https://api.github.com/users/ericchiang/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ericchiang/subscriptions","organizations_url":"https://api.github.com/users/ericchiang/orgs","repos_url":"https://api.github.com/users/ericchiang/repos","events_url":"https://api.github.com/users/ericchiang/events{/privacy}","received_events_url":"https://api.github.com/users/ericchiang/received_events","type":"User","site_admin":false},"created_at":"2016-06-15T00:16:18Z","updated_at":"2016-06-15T00:16:18Z","body":"For those following along this is what Google calls an \"Installed app\" which we plan to introduce to dex. Reading here: https://developers.google.com/identity/protocols/OAuth2InstalledApp\r\n\r\nSome highlights\r\n\r\n> * The client ID and client secret obtained from the Developers Console are embedded in the source code of your application. In this context, the client secret is obviously not treated as a secret.\r\n> * The authorization code can be returned to your application in the title bar of the browser or to an http://localhost port in the query string.\r\n\r\nAs for API access, native clients seem really dangerous when mixing with the cross client stuff we just introduced. If a client ever trusts a native client, then we should expect anyone to be able to login as that client.\r\n\r\nPreferably a native client would never be able to talk to the API, but then we'd have to setup rules to check the azp. blah.\r\n\r\n@bobbyrullo deprecating those APIs seem fine. Particularly when we already have implementations in the bootstrapping API, I'm okay with removing them in the user api."}}
{"actor":{"display_login":"ericchiang"}}