Jump to content

Talk:Auth systems/OAuth/Design

Add topic
From mediawiki.org

Using OAuth to verify the identity of a Wiki user

[edit]

One of the most important reasons that I have users log into their wiki account when they use WP:Snuggle is so that I can verify their identity (and good standing). I'm hoping that, when MediaWiki switches to an OAuth scheme, my users would not need to maintain a separate username and password in Snuggle in order to preserve an Access Token.

Unfortunately, OAuth is not an Authentication protocol. It is only meant to be used for Authorizing Snuggle to act on the user's behalf. If you need authentication, you'll want to look into OpenID. This blog post gives a good explanation of why this is the case. CSteipp (talk) 17:35, 5 June 2013 (UTC)Reply

So here's the question: What would my use case look like for a user who had previously provided permission to a wiki-tool (Authorization Token), but currently has not verified their identity with this wiki-tool?

Workflows for obtaining permission and verifying identity

[edit]

This is how I understand the workflow when a user has not yet provided permission:

  1. Client asks Server for Request Token
  2. Server provides Request Token to Client
  3. Client forwards the Resource Owner to the Server
  4. Resource Owner logs into server and verifies permissions
  5. Server forwards the Resource Owner back to Client
  6. Client asks Server for an Authorization Token (using Request Token)
  7. Server provides Authorization Token
  8. Client asks Server whoami (api.php?action=query&meta=userinfo)

At this point, Client has verified Resource Owner's identity and can act on his/her behalf.

This is how I assume the workflow will look like for a user who had previously provided permission, but not verified his/her identity (differences are highlighted):

  1. Client asks Server for Request Token
  2. Server provides Request Token to Client
  3. Client forwards the Resource Owner to the Server
  4. Resource Owner logs in, but has already provided permission
  5. Server immediately forwards the Resource Owner back to Client
  6. Client asks Server for an Authorization Token (using Request Token)
  7. Server provides the exact same Authorization Token it previously had
  8. Client asks Server whoami (api.php?action=query&meta=userinfo)

At this point, Client has verified Resource Owner's identity and can act on his/her behalf. Client would have no need to store the Authorization Token at all. Does this look right? --EpochFail (talk) 14:50, 5 June 2013 (UTC)Reply