2017-10-03 13:05:00+00:00

An end user client app needs to be able to access user facing services without intermediary.

It doesn't make senses that client app need to go through game player state service in order to fetch user guide article.

So instead of doing this:

We should be doing this:

By changing the component dependency, some network and CPU loads have been removed from the Game Playing State Service.

As the Wiki Service will be accessible via the Internet the same way the Game Playing State Service does, we need to put some access security on it.

When accessing the Wiki Service, we will use the same access token being used to access the Game Playing State Service.

Doing that, we only need to authorize the client once, and then use the resulting access token to access all public facing services we have.

How do we authorize a client app?

We need to have a login form user interface to allow users to enter username and password.

When the entered username and password are valid, the client app is authorized to access the resources on behalf of that user.

Who handles the checking of username and password?

Is it the Game Playing State Service? Or is it the Wiki Service?

The truth is that we need another service to check username and password. It called the Authorization Service.

The Authorization Service

After adding an Authorization Service, the component dependency is becoming like this:

Client Side App will access Authorization Server to exchange username and password with an access token.

Using the access token, Client Side App can access resources that are controlled by Game Playing State Service and Wiki Service.

By sending introspection request to Authorization Server, the Game Playing State Server and Wiki Server check the validity of the access token they have received from Client Side App.

References