should long lived access tokens be permitted

[Joseph Heenan]

This was brought up on today’s call; it would be good for people to document their thoughts on what statements on long lived access tokens (and hence the related issue of whether refresh tokens should be supported) should go into the FAPI-R or FAPI-RW specs and what should be covered in the implementation/deployment advice please.

[Freddi Gyara]

The OBIE specification relies on MA-TLS to strongly bind the token to transport layer as well. I guess this mitigates most of the downsides of long lived access tokens ?

[Joseph Heenan]

The argument is relatively finely balanced.

For FAPI-R (where there’s no token binding), long lived access tokens can easily leak and be used with no proof of possession so are (I believe) undeniably bad.

For FAPI-RW, the access tokens are bound as you say.

There are two possible approaches in FAPI-RW:

1. access tokens are self-contained. These have an obvious performance advantage as the RS/gateway doesn’t need to check with the AS on each API call - except they are then difficult to revoke, so to retain the performance advantage you pretty much have to make them short lived, and then you can avoid needing to revoke them. There are also cases where the client only uses an access token very infrequently, where the time overhead of calling the refresh token grant can negatively affect some use cases.
2. access tokens are verified with the AS each time. This almost always results in poorer performance, especially if the client is calling a number of APIs in a short space of time. It does make tokens easier to revoke, but revoking tokens (for example if a client’s permissions are downgraded) can still be tricky compared to the simplicity of the self-contained case where simplify modifying the client configuration solves the issue as the client config will be validated at the next refresh token grant.

‌

In the general FAPI-RW case, long lived access tokens also cause an issue with key rotation for clients, essentially meaning the refresh token grant would still have to be made available to permit obtaining a new access token bound to the new key. (I believe this isn’t an issue in OB due OB specifying that the tokens are bound to attributes of the certificate that would survive a rotation.)

‌

(There must surely be some existing standards somewhere we can refer to for some of this explanation?)

[Dave Tonge]

We discussed on the call that it isn’t advisable to directly couple refresh tokens and “consent”.

[Dave Tonge]

Potentially reference the security BCP

[Torsten Lodderstedt]

https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-3.2

https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-3.3

[Dave Tonge]

https://bitbucket.org/openid/fapi/issues/262/should-long-lived-access-tokens-be

[Freddi Gyara]

Some potential TPPs that we have been talking too have had given us feedback that the OBIE APIs are “quite chatty” because of the need to make seperate OIDC calls. They have been advocating the use of self-signed tokens or some similar mechanism to reduce the number of discrete API calls that are made. On one hand, we want to continue to be compliant with standards such as OIDC and FAPI, but we do not want to make the situation on API adoption any more difficult.

Introducing a compulsion around short-lived tokens would increase the number of calls the TPP would have to make to achieve a particular business outcome. Unless we have a very specific set of security benefits in doing so, I would recommend we not do that.

Another thing to be aware of is that a lot of the AIS calls execute as a batch from the PFMs / accounting software TPPs. This already causes spikes in usage. Short lived tokens that have to be refreshed just before use will make it even spikier.

[Joseph Heenan]

Freddi: Dave’s suggested text only applies to FAPI-R non-sender-constrained access tokens, so doesn’t affect OBUK.

That said, how does OBIE approach key rotation - if a bank is issuing long lived access tokens, do you expect that bank to allow the TPP to rotate their MTLS keys and for the access tokens to continue to work? Or is it okay to break long lived access tokens on key rotation so long as a refresh token was issued?

Did you view ‘10 minutes’ as “short lived”?

I can in general see what you’re saying, but it sounds like what the ‘self signed’ tokens these TPPs are asking for breaks the classical separation of responsibilities between the AS & RS and effectively disallows some security choices OBUK banks have made in their architectures?

[Freddi Gyara]

Understood - that is fine - just wanted to ensure that the OB context is stated here.

For key rotation, we do not state the method to be used in standards, but it has been made quite clear that it would be unacceptable for long-lived tokens / consents to be lost and a re-auth required due to technical changes. We recommend (but do not state in standards) that the ASPSP always issues a refresh token along with the long lived access token. The refresh token can then be used with a new cert to get an access token bound to the new cert. This should be compliant with mtls as long as the new cert’s tls_client_auth_subject_dn matches with the old certs.

If the tls_client_auth_subject_dn has changed as well (e.g. when a TPP transitions from OB legacy to eidas certificates), then they would first have to modify their client registration record. At this point, access tokens that have been issued would continue to function (as they are bound to the current certificate’s thumbprint and don’t rely on the tls_client_auth_subject_dn). Any tokens that are issued after the reg change would have to use the new certificate that is being rotated in.

‘Self-signed’ tokens definitely breaks OIDC, COTS products and good practice in terms of AS and RS segregation. However, once we start considering volume that FAANGs or similar could generate when using payment APIs in anger, it would be an optimization worth considering.

[Dave Tonge]

HI Freddi, to make OB APIs less chatty then these would help:

• webhooks
• embedding balance / product /etc. payloads in the main account payload

I think retrieving and refreshing tokens is a red herring.

To Joseph’s point, this suggestion doesn’t apply to sender constrained tokens.

‌

[Dave Tonge]

PR merged