Banno Authentication Framework

Plugins built using the Plugin Framework use the Authentication Framework to provide secure authentication.

Authentication Framework

User data is protected using OAuth 2.0 and OpenID Connect.

• API access is provided via an Access Token (OAuth)
• Authenticated information about the user is provided via an Identity Token (OpenID Connect)

OAuth 2.0

With OAuth, users can delegate scoped access to the plugin to act on the user’s behalf. The user’s login credentials are never shared with the plugin. Rather, authorization is provided to the plugin via an access token (format JWT: https://en.wikipedia.org/wiki/JSON_Web_Token).

Proof Key for Code Exchange (PKCE)

Vulnerabilities were found in the OAuth 2.0 Authorization Code grant type. In OAuth 2.0, public applications in the browser can be exploited via authorization code interception. A malicious application running alongside your application could intercept the authorization code sent from the authorization provider and obtain the authorization token. PKCE is designed to fix those vulnerabilities.

OpenID Connect

OpenID Connect is an identity layer built on top of the OAuth 2.0 protocol. With OpenID Connect, the plugin is provided authenticated information about the user in the form of an identity token (format is JWT).

Permissions Flow

The permissions flow is how plugins get permission to access user’s protected data. Permission can be restricted or denied by any of the following:

1. Banno Platform: Banno restricts data access in 2 ways:
   • The endpoints that are made available
   • Specifying which scopes and claims are necessary to access an endpoint
2. Financial Institutions: FIs can choose to limit which data is accessible across their entire user base.
3. Plugin developers: If the plugin developer does not request specific scopes and claims, then the related data will not be included in the response.
4. End User: Users are presented with a consent screen to grant or deny the permission requests.

Scopes

The set of scopes the plugin developer passes to the authorization request determines the permissions the user is required to grant. Scopes enable your plugin to access specific API endpoints on behalf of the user.

Claims

Claims allow access to authenticated information about a user.

Consent Experience

The end user is presented with a consent screen that lists all the scopes and claims that your plugin has requested.

Once the user has allowed your plugin to access his data, the plugin is a Connected App. The user can review all their connected apps from their Security settings.

The user can view or revoke consent at any time.

Using Access Tokens

API Requests must include the Access Token as a bearer token in the header.

Identity Tokens

Your plugin gets authenticated user identity information via an Identity Token, which is encoded in JWT (JSON Web Token) format. The kind of information provided depends upon the scope parameters requested.

Example decoded Identity Token: