Consideration on how to apply multiple FAPI and its related security profiles dynamically
We have implemented FAPI 1.0 and its related security standards to the OSS (keycloak : https://www.keycloak.org/ , https://github.com/keycloak/keycloak). During this work, we have found some points we want to share to make FAPI Security Profile more beneficial.
In this talk, we will pick up one of such points, how to apply multiple FAPI and other security profiles dynamically per client’s request.
Considering the situation that a client wants to apply a security profile like FAPI per its request. For example, if the client sends an authorization request with scope parameter including “readonly”, the client expects that FAPI 1.0 Baseline security profile be applied by an authorization server. If the client sends the authorization request with scope parameter including “readwrite”, the client expects that FAPI 1.0 Advanced security profile be applied.
Generally, we can achieve such changing security profiles per client dynamically. However, if the authorization server executes security profile related logics based on values of OAuth 2.0/OpenID Connect client metadata, the following issue may arise.
For example, “tls_client_certificate_bound_access_tokens” is picked up as such the OAuth 2.0 client metadata. The client described above sets “tls_client_certificate_bound_access_tokens = true” explicitly by itself or the authorization server enforces the client to set it to follow FAPI 1.0 Advanced security profile.
When the client wants to access the API requiring “readwrite” scope value for accessing some resource owner’s resource, the client sends the authorization request with scope parameter including “readwrite” in mutual TLS handshake and the authorization server accepts this request.
Consecutively, when the client wants to access the API requiring “readonly” scope value for accessing other resource owner’s resource, the client sends the authorization request with scope parameter including “readonly” in normal TLS handshake. In this case, the authorization server rejects this request because the client sent it without mutual TLS handshake. FAPI 1.0 Baseline security profile does not require Holder-of-Key bound access token so that this request should be accepted.
If the client changed its client metadata before sending this request, the authorization server would accept it. However, by considering the additional workload incurred by this additional changing metadata request, it is not a practical way.
To resolve this issue, we propose three strategies for executing security profile related logics : one security profile per client, resolving conflicts in advance and policy-based logics overriding default client metadata setting based logics. Moreover, we discuss which strategy fits with which use case for securing APIs.