Security: granular and temporary access to the API; even better a Teller App Store?

[sebinsua]

I'm aware that you're already working on something related to this but I figured an issue should exist for it. :)

---

Currently there is just a personal access_token and it gives you read/write access to everything that is available forever.

Obviously this is risky - a leaked token fully exposes you. This means that wherever the token is stored has to be very secure and a user will need to completely trust any business or app that stores this token on their behalf.

I can see a full solution being kind of complex and I think what's required are some kind of stepping stones towards the right solution.

First of all:

1. I would like a way of refreshing a token. A red button 🔴 to press if I accidentally leak it.
2. Tokens should be read-only by default.
3. I want to be able to be notified of new IPs using a token via SMS or email. Just in case.

I think the overall goal should be the creation of a portal for consumers to register on that allows them to manage the Apps that have access to their account. Similar to what exists for apps on Facebook. A Manage Apps area of the site.

However, it's not enough to just hand control to consumers; their risk of exposure has to be low by default.

Different apps require different levels of access. This is probably the next most important thing after the worst-case scenario stuff I mentioned in the numbered list.

A decision needs to be made on what kinds of apps will operate on the service to begin with and what security defaults they will have:

• Can I give an App specific access to one-or-more of my accounts?
• Should there be some kind of 2FA process to grant an app access or something else entirely?
• Can an app be given only temporary access? Say 5 minutes.
• Should long-running auth tokens be refreshed from time-to-time?
• Is the term write-access useful? It seems that the boundaries between different permissions are kind of a continuum between:
  • read access to my current account
  • read access to all of my accounts
  • read access to a current account with purchases that I wish to remain private
  • write access to name accounts or tag transactions, etc. Metadata.
  • write access to move money between accounts
  • write access to pay a previous payee a small amount of money
  • write access to pay a previous payee a large sum of money
  • write access to pay a new payee a small sum of money
  • write access to pay a new payee a large sum of money
• Is privilege escalation a thing? Can I metaphor-for-sudo an action?

This isn't something I'm super experienced with so I can't offer much help coming up with standardised solutions. This is just a cross-section of my thoughts right now - if you have a business you are integrating with probably you should just do whatever helps them first, but I think what I need will just be a way of (1) granting explicit permissions to an app - read-only to start with, (2) getting an overview of what apps have access to my data, and (3) managing the apps that were previously granted access.

[stevegraham]

Here is my current thinking:

Developer side

The access token is just a beta mechanism. When Teller is generally available it will certainly use a different mechanism for authentication.

Things I'm currently considering:

• Modified OAuth 2.0 using SSL client certificates
• A new auth mechanism using SSL client certs to identify the requester at OSI Layer 6, and using the SSL cert private key to digitally sign each request at OSI Layer 7 providing full non-repudiation.

Developers will have to use client SSL certs, I don't see a way to assert the integrity of the connection without mutual authentication.

I am implementing functionality for you to rotate your beta access token.

End-user side

Authorising developer access

• Will be 2FA. Eventually there will probably be a Teller mobile app for end-users and authorising 3rd party access will be contained within a la how FB does it.
• Before this 2FA will be done via SMS. The will look something like this:
  • User is bounced to Teller to authorise the developer.
  • User enters mobile number on the auth screen
  • Teller sends a OTP vis SMS
  • User enters OTP
  • if user is already registered with Teller
  • Standard OAuth dialog is shown explaining developer identity, app purpose, permissions requested, lifespan of authorisation, etc.
  • else
  • User is directed through the flow to add account(s).
  • Flow continues as above
  • User is redirected to 3rd party with authorisation result.
• Users will be able to see who has access, what they've been up to on your account (BTW this is already being logged, e.g. activities with your personal access token), and be able to revoke access at any time.

Scopes

There will read and write scopes at least, as that makes total sense. I need to do user research to see what level of granularity is appropriate (FYI this issue is great user research ☺️). I think read == viewing stuff and write == moving money is fine. In terms of meta data, all developers should be able to write metadata but this would be scoped to the authorisation, i.e. apps will not see or be able to modify metadata from other apps.

Some things I'm thinking about:

• Granular authorisations per account, e.g. read-only on account 1, no permissions on account 2 making it de facto invisible to the 3rd party.
• Limits for remittances on write permissions, e.g. £50/month
• Short lifetime authorisations, e.g. 30 mins for credit check / identity check applications etc

[stevegraham]

Been working on the SSL client cert generation. Want to make it as painless as possible. Check it out: https://www.youtube.com/watch?v=Qp4_jP_40vU