roll-network/oauth-client-example

oauth-client-example's Issues

create api class to ease authentication for third party apps

goals

• Make log in / log out easy for 3rd party apps
• automatically handle token refresh
• expose functions to make interaction with the Roll api quick and easy

I am designing this class to achieve these goals with as little assumptions about the consumers implementation as possible.

currently I am allowing the class consumer to decide how they handle:

• caching access and refresh tokens
• the logged in/logged out state of the roll account in the context of their whole application
• the way they navigate to the roll login and logout pages

Initializing the api class will look like this:

const rollAPI = new RollAPI(
  clientID,
  issuerURL,
  redirectURL,
  scopes, // array of scopes ["read", "write"...etc]
  cacheOauthTokens, // optional function written by consumer to set the oauth tokens in a caching mechanism
  getCachedOauthTokens, // optional function to return the cached tokens
  clearCachedOauthTokens // optional function to clear cached tokens
);

The consumer will log in like this:

window.location.href = rollAPI.getLoginURL()

//// once the redirect url is hit...

 rollAPI.initializeSession(
          window.location.search, // the callback url container the ?code=123 param
          handleSuccess, // callback to be invoked when the user becomes authenticated, and when tokens are refreshed
          handleFail // callback to be invoked when login or refresh fails
        );

The consumer will log out like this:

window.location.href = rollAPI.getLogoutURL();

cacheOauthTokens: (oauthTokenOBJ) => void
getCachedOauthTokens: () => oauthTokenOBJ
clearCachedOauthTokens: () => void
handle success: () => void
handleFail: (err) => void

cc @sidko here are some notes on how I am implementing the roll api class.

Expand the example for write scope

We need to expand the scope of the sample client example to include write scope.

As part of this issue, we will only test the internal send flow. The user workflow is as follows: I should be able to connect my Roll account to the client-example, approve the permissions, and then tip a user.

The following need to be tested:

• If the user denies access to client-example, the client-example should not be able to send any social money.
• The client-example should not be able to send social money on behalf of a user before going through the permission flow from the user.
• The client-example should not be able to send in excess of the daily limits for the user.
• The client-example should be able to send social money after the 24 hour period has elapsed for the daily limits.

The following components are needed on the UI:

• Pre-fill some accounts for the user to tip to - Bradley, Sid, Marlon, Ashish, Gaurav, Sinkas to start with.
• Let the user specify the recipient, token, and amount.
• Throw the message received from the server to the frontend

Verify the app uses the token of the logged in/connected user when making API calls

Some external users have been using a universal auth token to call read-only API endpoints. We want to move to a system where we are using the auth token of the logged in user to manage all calls for that user. If multiple users are connected, then each users' calls should use that user's auth token. This is until we have a client credential flow where the app can use its own auth token. See https://github.com/TuringAdvisoryGroup/product/issues/19

• Test all the flows are still working after we did some backend changes. Specifically, make sure the hasbalance endpoint is working right
• Connect several users to the app. Have the example app make API calls on behalf of these users (read only, write, etc.) Make sure that each call is using the authorization for that particular user

CC @marlon-wiprud