Designing OAuth2 Resource Server (RS)

How to design a OAuth2 Resource Server (RS)? Do I even care – shouldn’t there be already several existing open source implementations? Well, not exactly. The only implementation I have found is Authlete. In addition, the OAuth2 specifications are not covering Resource server implementation.

Different things to consider:

In OAuth2, you grant a (client) application to access a resource in RS on behalf of the user / resource owner / you. The client needs have an access token in order to access the requested resource. The level of access is defined as scopes, which are part of the OAuth2 standards.

What does a scope mean? Oauth2 scopes are used to express what app can do on behalf of a user. They are used for handling delegation scenarios. Resource endpoints are responsible for combining the incoming scopes and actual user privileges to decide effective permissions and make access control decisions. In a way, scope is a aggregate / interface which is then implemented on RS – and not on the Authorization server (AS)! In AS, clients are managed, all available scopes are managed, and UI for allowing user to give consents are there.

Resource server access control should start with HTTP CRUD access control: i.e. POST, GET, PUT, DELETE. See my other post about organizing REST APIs! Identity of a user comes from a same domain JWT ID Token, so the user information is present. Note that scopes are client specific and they are basically transformed into access control policies! What I mean by this is that actually scopes cover only a subset of all access rights in RS! So what people usually get wrong when designing a RS is that they think that scopes are the basis of controlling access to resources. Unfortunately, I haven’t found any good resources on designing this part – have you?

OIDC Is Just OAuth2 Flow

What is OAuth2? It is a security framework that can be used to grant a Client Application a right to access a (remote) resource that is usually some digital object. For OpenID Connect (OIDC) that particular resource is the “openid” user identifier. The reason for writing this post is that it took for me quite long to finally understand that OIDC is ultimately OAuth2. The two images below depict the operation of the OAuth2 in different ways. The core idea is that to access a resource like “openid” you need a valid access token. So it is fair to say that OIDC extends OAuth2, but the spec is not very clear where for example authentication takes place or where the OpenID Provider (OP) is located. The conclusion I came to was that there could have been a better way to specify the OIDC. How? Well, Identity Provider (IdP) could have been specified as a separate server i.e. Identity server. Also, separate Authorization server (Authority server) should be present, and finally the “openid” should be located in the Resource server as an object! Note that Relying Party (RP) is the client app that receives the Access token

oidc is just oauth2

(source: oracle.com)

What are the commonalities and differences between State Machines and Reactive Streams?

What are the commonalities and differences between a State Machine (SM) and a Reactive Stream (RM)? Recently, I read about reactive programming. I also have previously written about state machines. I realized that there are some extremely interesting commonalities and differences between them!

Commonalities. Both SMs and RSs can be represented as graphs. A node and an edge correspond to a state and a transition, respectively. A node can be understood either as a whole or a partial system state or as a data processing step. Typically, a transition can be understood as a event, but as I have written in my previous post, “events, conditions, and actions” constitute the set of all possible transitions.

Differences. A state machine is exactly at one state at any given time whereas a reactive stream is in a some state at any give time: data flows through a path of states. The SM has exactly one start and end point, but RSs have possibly multiple publish (start) and subscribe (end) points.

Insight. State machines and reactive streams look similar but they are different but in the most interesting way:

  • A state machine is a stateful representation of a directional graph of states with one start and end state.
  • A reactive stream is a stateless representation of a directional graph of flows with multiple start and end states.
  • A data model of a system is a state representation as a directional graph of data attributes with multiple connected subtrees (cf. JPA entity graphs!)

Hail, Graphs! The message that I am trying to convey here is closely related to new kind of programming which is discussed very well here (text) and here (video).