{"action":"created","issue":{"url":"https://api.github.com/repos/mozilla/teach-api/issues/31","repository_url":"https://api.github.com/repos/mozilla/teach-api","labels_url":"https://api.github.com/repos/mozilla/teach-api/issues/31/labels{/name}","comments_url":"https://api.github.com/repos/mozilla/teach-api/issues/31/comments","events_url":"https://api.github.com/repos/mozilla/teach-api/issues/31/events","html_url":"https://github.com/mozilla/teach-api/issues/31","id":145769750,"number":31,"title":"credly authentication exploration","user":{"login":"Pomax","id":177243,"avatar_url":"https://avatars.githubusercontent.com/u/177243?v=3","gravatar_id":"","url":"https://api.github.com/users/Pomax","html_url":"https://github.com/Pomax","followers_url":"https://api.github.com/users/Pomax/followers","following_url":"https://api.github.com/users/Pomax/following{/other_user}","gists_url":"https://api.github.com/users/Pomax/gists{/gist_id}","starred_url":"https://api.github.com/users/Pomax/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Pomax/subscriptions","organizations_url":"https://api.github.com/users/Pomax/orgs","repos_url":"https://api.github.com/users/Pomax/repos","events_url":"https://api.github.com/users/Pomax/events{/privacy}","received_events_url":"https://api.github.com/users/Pomax/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/mozilla/teach-api/labels/question","name":"question","color":"cc317c"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":18,"created_at":"2016-04-04T18:39:51Z","updated_at":"2016-04-08T18:36:53Z","closed_at":null,"body":"Since we're currently exploring intergrating credly access through the Teach-API, the issue of user account knowledge will need to be tackled. Both wmo and credly require a login, but depending on who does what, it feels like the wrong services might be managing credentials.\r\n\r\n## The basics\r\n\r\n- Webmaker login is owned by us, and users authenticate in via oauth2 with a username and password, after which the logged in service knows the user's username and account email address.\r\n- Credly login is owned by credly, and users are authenticated in apps by requesting an auth token with that user's username and password, after which the token needs to be periodically refreshed to stay active (which does not require the user's name/pass combination) or needs to be re-requested if the token already expired (which does require the user's name/pass)\r\n\r\n## The Teach-API\r\n\r\n- when users log into the Teach-API through the wmo oauth2 service, they are stored as local users by Django. Django does its own magic, by calling `django.contrib.auth.login` at the end of a successfull oauth2 wmo login, and so we locally have users with usernames and django-managed mystery passwords that we don't use for anything.\r\n\r\n## Tying those things together\r\n\r\nThe question we need to answer is \"what is an acceptable way to make sure users can log into Teach, as well as Credly, with the right people owning the right credentials\". There are two possible cases here:\r\n\r\n### A new user (as far as Credly accounts go)\r\n\r\nWhen a user logs into Teach and we do not have Credly information for them on file, we can make an account for them.\r\n\r\nThe simplest way to do this is to register an account for them with their email address and the magic Django password, but if we do that, the user needs to be told what their magical Django password is. While you can't log in with that password, exposing it seems the wrong way to go about things.\r\n\r\nAnother option is to track wmo and Credly logins separately: signing into Teach will not in any way log you into the part that deals with Credly, and instead we have some explicit UI on the badges page(s) that says \"If you want to earn badges, we use Credly for badging. Click [here]() if you'd like to make you a Credly account, or if you already have a Credly account, click [here]() to start using your account for MLN badges\", with those two bits of UI respectively doing:\r\n\r\n1. ask the user for an email address and a password to use with Credly , then run through Credly's `authenticate/register` API route from the Teach-API server (so without making users visit Credly's website; they stay on Teach) to set up their account, without storing their password anywhere ourselves. Registration automatically gets us an access token (which we can use to act on behalf of the user) and refresh token (which we can use to get a new access token without needing the user's Credly login) back. We could prefill the email box with the user's webmaker email if that makes things easier for the user, but it should be possible for the user to use a different email address. We store the token and refresh token only.\r\n\r\n2. ask the user for their Credly email address and a password, then run those through Credly's `authenticate` API route from the Teach-API server to (again without storing their password anywhere ourselves) get an access token and refresh token back. We store the token and refresh token only.\r\n\r\n### A preexisting user\r\n\r\nWhen a user logs into Teach and the Teach-API sees that there is already an access token associated with the user, we can refresh the token so that we're not using a previous session's token (we can, tokens expire after 3 months, but it's always better to refresh) and then use this for signing server-side Credly API calls (paired with our own Credly API key and secret) for badge operations.\r\n\r\n# requirements\r\n\r\nI know we don't really like multiple logins, but from a security point of view I don't think we can get around the fact that using the same login information for Credly as we do for Teach would probably lead to potential risks that can be avoided by explaining to the user that we're using Credly and that they can either make an account with Credly on their own, or we can do that for them, to make the process as low-threshold as possible while staying secure.\r\n\r\nFrom a user experience point of view, we can make sure we don't tell people they need a Credly login until they actually express interest in badges by visiting any of the badges pages. Buttons like \"claim this badge\" can be replaced with \"sign up/in to earn badges\" buttons when there is no Credly access token known for the user, and we can add something to the main badges page like \"Interested in our badges? Sign in/up for badges to easily see which badges you've earned, and which ones you haven't\"?\r\n\r\nThoughts @flukeout @hannahkane @xmatthewx @simonwex @alanmoo?"},"comment":{"url":"https://api.github.com/repos/mozilla/teach-api/issues/comments/207550196","html_url":"https://github.com/mozilla/teach-api/issues/31#issuecomment-207550196","issue_url":"https://api.github.com/repos/mozilla/teach-api/issues/31","id":207550196,"user":{"login":"Pomax","id":177243,"avatar_url":"https://avatars.githubusercontent.com/u/177243?v=3","gravatar_id":"","url":"https://api.github.com/users/Pomax","html_url":"https://github.com/Pomax","followers_url":"https://api.github.com/users/Pomax/followers","following_url":"https://api.github.com/users/Pomax/following{/other_user}","gists_url":"https://api.github.com/users/Pomax/gists{/gist_id}","starred_url":"https://api.github.com/users/Pomax/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Pomax/subscriptions","organizations_url":"https://api.github.com/users/Pomax/orgs","repos_url":"https://api.github.com/users/Pomax/repos","events_url":"https://api.github.com/users/Pomax/events{/privacy}","received_events_url":"https://api.github.com/users/Pomax/received_events","type":"User","site_admin":false},"created_at":"2016-04-08T18:36:53Z","updated_at":"2016-04-08T18:36:53Z","body":"1. A is entirely doable, let's go with that.\r\n2. I assumed would look similar to logged in, except for an \"apply\" button we'd instead have the \"you need to log into MLN to start earning badges\" login button."}}