1. David Larlet
  2. django-oauth-plus
  3. Issues
Issue #37 open

Token name

Vladimir Prudnikov
created an issue

Each token should have a name associated with it.

Usual workflow — a web service and some desktop client. One user can have more than one token created for the same client on different machines. When user grants access it should be possible to name this token. Say "CoolApp on personal laptop", "CoolApp at work" etc. Later if user wants to revoke access to some client he can differentiate them.

Comments (4)

  1. Michał Jaworski

    I understand your issue but there is no place for named tokens. I don't know a good place for such naming in authorization flows we support. Note that both three-legged and xAuth flows should be supported and this can't be done without extending OAuth protocol.

    I understand your usability problem and there is already way to solve it. What you can already do is to name Consumer objects – place where you hold api key and secret. Every Access and Request Token is related with one Consumer object. This is how oauth_provider finds out who is accessing resources. Give your's API users (service consumers) option to create multiple API keys (Consumer objects) and to edit them. From now you can use it as a description of Access Token for real users (resource owners).

    You can even extend Consumer with OneToOne relationship and create a kind of CosumerProfile with company logo, detailed description etc. You can then show this information to user on authorization step, so users will know who they authorize.

  2. Vladimir Prudnikov reporter

    1) This is not for authorization flow, this is for management. It has nothing to do with OAuth protocol, it's just internal implementation of OAuth Provider. 2) Consumer name is different thing.

    Let me explain with Evernote as an example. Evernote has a public API with authorization using OAuth protocol. They also have Evernote desktop client and bunch of other 3rd party apps. Each app has its own Consumer object. The names for the Consumer may be "Official Evernote Client for Mac", "Some 3-rd Party Client App", etc. Those are consumer names.

    Now imagine I have 3 Macs and use "Official Evernote Client For Mac" on all of them. I have 3 Access Tokens for them. Now I want to revoke access token for one of them (for example macbook is stolen), I open page with list of access tokens and see 3 times "Official Evernote Client For Mac". There is no way to differentiate them. Named tokens can solve this issue.

    When user visit Authorize Request Token page he will see a form (AuthorizeRequestTokenForm) not only with checkbox "[x] Grant Access", but also with the optional input for name.

  3. Michał Jaworski
    • changed status to open

    I could't understand you because I have never seen such use case. Now I understand your point of view, but I'm not sure if this is good enough reason for adding name field to access token. It would be best if such change would be fully optional so i it won't affect all project's that are already using oauth_provider.

    I think this should be independently solved by custom authorization view and form. Other objection is that such prompting user for access token name doesn't increase user experience.

    If I cared for such problem I would rather give option to consumers in relieving users in naming their tokens or even relive consumers in that work.

    I've reopened this issue because discussion is still open.

  4. Vladimir Prudnikov reporter

    Yeah, it does not increase UX of request token authorization process, but it does increase UX of managing of access tokens.

    It can't be easily done by just adding name field (default is None) to the model and creating additional form that will contain name field. Developer could choose what form to use by specifying form class in settings.

    Take a look at Django Registration where multiple form classes available.

    I'll do this functionality for my project soon, so, I can implement it and create pull request.

  5. Log in to comment