credly authentication exploration

[Pomax]

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.

The basics

• 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.
• 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)

  The Teach-API

• 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.

  Tying those things together

The 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:

A new user (as far as Credly accounts go)

When a user logs into Teach and we do not have Credly information for them on file, we can make an account for them.

The 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.

Another 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:

1. 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.
2. 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.

   A preexisting user

When 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.

requirements

I 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.

From 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"?

Thoughts @flukeout @hannahkane @xmatthewx @simonwex @alanmoo?

[Pomax]

A diagram of sorts to somewhat (hopefully) elucidate the suggested solution, although I'll be happy to redraw it as something more specific on request

/cc @xmatthewx, for additional brainstorming powers

[hannahkane]

I really like this solution, @Pomax, and would love @xmatthewx's thoughts on the UX, too. I think we can take this opportunity to share a value proposition, as @simonwex suggested. Something like, "Credly allows you to earn and store digital badges and credentials from a variety of education providers and services, including Mozilla." This doesn't need to be front-and-center, but I think it is a useful piece of information for people.

[xmatthewx]

Nice work untangling this @Pomax. Interesting solution to an odd problem. Sorry for the length of this comment.

Summary

I'll attempt to summarize the proposed experience to make sure I understand it and hopefully uncover any snags:

1. User sees an Activate Badges button.
2. Click. This requires them to login to our system if they aren't already (unless those parts of the site are inaccessible to unauthenticated users).
3. User sees the value prop nicely phrased by @hannahkane "Credly allows you to earn and store digital badges and credentials from a variety of education providers and services, including Mozilla."
4. User sees a typical Login / Signup experience (Credly branding helps avoid confusion)
5. If they choose Signup, they're given an atypical choice:
   • Create an account
   • Let us handle that for you
6. Regardless of their choice on this visit, we can manage their future logins. [true or false?]

Thoughts

This is unorthodox, but:

• as @Pomax said, users don't learn about Credly until they've expressed interest in badges.
• it's useful to surface Credly since people will hopefully leverage badges beyond their Mozilla experience.

Questions

Can we think of other cases where a third party tool requires unique login? I think my university did this. It's potentially annoying. I wish a good precedent jumped to mind.

Can we abstract parts of both login experience like error messages for easier maintenance? cart before the horse

If we handle a user's Credly signup, they can still login to Credly elsewhere by reseting their password. True? Would they need to reauthenticate when they return to Mozilla? That's okay, but will require some UX attention.

Have we talked with Credly about how others handle this? Just checking. I assume yes.

Tentative Conclusions

Login. Like a weed, it seems to crowd around our feet every spring. This scares me. It is a sensible solution to a complicated problem. I fear the dragons we'll discover. There are several tradeoffs in both engineering and experience, but I think @pomax struck a good balance.

I recommend we whip up some wireframes and test on usertesting.com.

[Pomax]

for (5), do we want to offer option 2 at all? I see two possibilities:

i. we give them an email+password field, with the same email they use for webmaker prefilled in, but they can change it, and an empty password field ii. we don't give them anything and simply use their webmaker email address and a random password, but then we need to somehow securely inform the user what that password is, which is a responsibility we can easily mess up (because security is hard =D) and then inform them that we've generated an account with a random password that we don't even store, and if they want to log in to credly.com they'll have to request a password reset because we won't be able to help them with that even if we wanted to.

If we handle a user's Credly signup, they can still login to Credly elsewhere by reseting their password. True? Would they need to reauthenticate when they return to Mozilla? That's okay, but will require some UX attention.

Entirely true - I don't actually know if they need to reauthenticate. I would hope not, since the access token is tied to their account, not their password per se, but that's something worth looking into. Our idea is that when we log a user in, we get an access (expires after 90 days) and refresh token, so after receiving those we can automate the process of refreshing the access token before it expires, so that users only ever need to log in through us once, and then never have to be faced with that again (unless we lose our database or something equally horrible happens)

Can we think of other cases where a third party tool requires unique login?

At least in the dev world, things like Heroku etc. come to mind, where you have a login, but if you want to tie into a third party service like github etc. you have to do a one-time authorization for each third party service you want looped in.

[xmatthewx]

Okay cool. I misunderstood. Let's not offer to create an account for the user, unless we discover a compelling reason. Nix that, and we reduce the complexity of this project, both tech and ux.

[hannahkane]

+1 to giving them the single option with a pre-populated email and blank password field

Other cases - tools like Hootsuite or Tweetdeck that do a one-time authentication against social media accounts. That reminds me, do we need to provide a workflow for people who want to disassociate their Credly account from us for whatever reason? Probably a rare edge case. Maybe handled on Credly's side?

[xmatthewx]

@Pomax just mention that we should frame this clearly as a one-time thing. Login or signup once, never worry about it again on our site.

Let's not worry about the edge case. We have plenty of those we haven't handled for our own authentication. If Credly is like other services, they probably have a way to manage associated apps.

[hannahkane]

during stand tomorrow, I'd like to discuss whether we can push a version out before landing on a final, tested workflow here. we're going to miss our window to get this tested in the current school year if we don't push this soon.

[hannahkane]

oh shoot - @pomax, you won't be at stand tomorrow. let's discuss here. I'm wondering if we can push this out as designed so far, and instead of testing on usertesting.com, we can actually just put this in front of our pilot project members immediately and see if/where there are problems.

[hannahkane]

and by "put this in front of," I might mean on a staging server. doesn't need to go to production if we can give a small set of people access.

[xmatthewx]

If you have real users that can help test... by all means.

[Pomax]

I can be in the stand tomorrow, if if you prefer, we can schedule a vidyo meeting sometime today or tomorrow. I am always available for questions or discussions.

[hannahkane]

calendar invite sent for quick pre-stand discussion tomorrow morning

[xmatthewx]

Badge List Page

@Pomax - are you following the login conventions in the comps? With the button above all the badges? And, no buttons to claim/apply anywhere if a person is not logged in?

If so, I propose we use the same space to prompt for Credly connection if needed.

[Pomax]

I am; I actually have placeholder code for users to log into credly if they're logged into wmo but not credly atm, so switching that to the "connect" button which then pops up the modal asking for email + password should be relatively little work.

We probably also want to have users connect if they don't click it on the /badges page but have directly navigated to a specific badge's page, right?

[xmatthewx]

Yes. That would be good if it's not a pain from your end. Many who login with that unique banner button won't notice that there's a new one in it's place. It will, however, be noticed by many who are already logged in.

[xmatthewx]

Badge Detail Page

A couple of questions on badge detail page:

1. Logged in:
   • Option A: we keep the current design as is (form with "Apply" button), and add a modal interstitial when needed. Is this possible? my preference
   • Option B: we include a button with a slightly different phrase: "Hi [username]! Connect to Credly to apply for this badge."
2. Logged out:
   • I found a comp of a badge detail page for logged in users, but not logged out. What does that look like? Does the whole "Apply for this badge" header, field, and button get replaced with a login button?

p.s. I tried to draw up a matrix of all the various states to design this holistically. Accounts² gets complicated. I feared it would slow us down too much. I hope this ad hoc approach is okay with you.

[Pomax]

1. A is entirely doable, let's go with that.
2. 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.

Also I'm fine with either case matrices or adhoc solutions, as long as we cover the cases we care about =)

[xmatthewx]

1. Great
2. Maybe ok for now.
   • My concern: someone fills out the form diligently and attaches documentation. Then the begin our sign up flow. Then the Credly connect flow. That seems fragile. Accidental back button?
   • Alternative: if not logged in and connected, hide the form.

[Pomax]

Ah, sorry yes my bad: you'd see everything except the "apply" related bits, so no "apply button" (instead it's the 'log into MLN to earn...' button), and no form for you to fill in evidence; but we would show the badge picture, title, description, requirements, etc.

Trying to preserve the form gets even more fragile, because the wmo login navigates you off-site in order to authenticate, so all the form data would get lost unless we do clever localStorage things that are going to eat up hours better spent on user testing.

[xmatthewx]

Connect to Credly

Draft modal. Note: link to Credly terms. For this action, I'd guess we don't need ours again, but I'm not qualified to decide that.

[Pomax]

good call on the EULA links - I wonder if there is a way we can be explicit here and say that unlike our own login, we will not store these values anywhere, not even temporarily; we're going to throw them away right after sending them on to Credly to obtain an access token, before we even get the token response back from Credly.

[xmatthewx]

Right. Interesting. Umm.... "✓ I understand that I am creating a Credly account according to their privacy policy and terms. You will connect my accounts, but not store any of this information."

[Pomax]

wfm in the interim =)

[xmatthewx]

Badge Detail Page

[xmatthewx]

@hannahkane – I believe @pomax and I have a pretty good draft to implement. There will definitely be hiccups and room for improvement (and a need for a legal review). But, I think that it's good enough to try. Please share with appropriate caveats!

• Badge list view
• Badge detail view
• Credly sign-up sign-in (with link to their policies)

[hannahkane]

hooray! Thanks for speedy work on this.

[Pomax]

this has landed.