Session Proposals

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.

JSON Web Proofs: Selective Disclosure & Unlinkability using JOSE

Work is proceeding on a new JOSE primitive called a JSON Web Proof that is very similar the JSON Web Signature spec, but adds the ability to support selective disclosure and unlinkable proofs.

The draft is located at https://github.com/json-web-proofs/json-web-proofs and initial incubation work is being done at the Decentralized Identity Foundation in the Applied Cryptography Working Group (https://identity.foundation/working-groups/crypto.html).

This session will provide an overview, discuss some potential use-cases, and answer any questions.

Lauritz Holtmann

Single Sign-On Security: Security Analysis of real-life OpenID Connect Implementations

I would like to discuss the outcomes of my master's thesis on SSO security that was finished in September 2020: https://www.nds.ruhr-uni-bochum.de/media/nds/arbeiten/2020/11/30/Masterarbeit_Lauritz_Holtmann_Single_Sign-On_Security.pdf

In this thesis, multiple IdPs and SPs were evaluated regarding the OAuth BCP and previous research, and common issue patterns were derived. Furthermore, the thesis includes some proposals for extensions of the security considerations.

Attribute-Based Encryption for Access Control in Cloud Ecosystems

In this talk I'd like to introduce our distributed, fine-granuled, policy-based resource access control protocol leveraging on Attribute-Based Encryption. The protocol is intended to explicitly address issues such as grant confidentiality, proof of possession, antiforgery... and may be implemented by complementing Oauth 2.0 Implicit Grant flow with a HTTP challenge-response authentication. Also I'd like to show a demo built on our Java-based prototype ABE4JWT (https://github.com/netgroup/abe4jwt). (Suggested duration of this session is 1h+questions). Thanks.

Daniel Fett

State of the Clients

Many OAuth client implementations are not tracking the progress made in the OAuth world regarding security and interoperability. In particular, only a few clients by default follow the OAuth Security BCP or provide the featureset required for FAPI compliance.

In this session, I would like to discuss strategies to track and improve client adoption of security guidelines and interoperability features.

This is based on a discussion started in the OpenID FAPI working group: https://bitbucket.org/openid/fapi/issues/433/track-fapi-compliant-rp-libraries

Daniel Fett

DPoP: Current status & next steps

Let's discuss the current status of DPoP and the next step for this draft.

BFF for Blazor WASM

IETF has already recommended Backend for Frontend Security(BFF) for SPA. I am big fan of BFF and have implemented for angular SPA. BFF has two main point.

Don’t Use Implicit Flow (Already Deprecated in OAuth 2.1)

Don’t store access or id token on browser.

I am trying to implement the same in Blazer WASM. By default WASM template still store security token in browser side. This is what I have done.

https://som-nitjsr.github.io/bff/2021/04/25/BlazorWASMBFF.html

In order to be able to create or vote for proposals, you need to be logged in. you can log in and register here