Microfy / Authentication

"Service to Service" authentication for your docker swarm microservices - solved.
0 stars 0 forks source link

Authentication Server Service #1

Open dazinator opened 3 years ago

dazinator commented 3 years ago

As per readme, develop the AS.

dazinator commented 3 years ago
  1. Will provide an endpoint: /api/token that callers can use to exchange a valid client id, and client secret, for a signed JWT.
  2. Environment variables:
    • Issuer name (for JWT Issuer field)

Administration

Adding a new oauth client

So there is a new service called foo that needs to authenticate. It will need a client id and client secret that it can send to the /api/token endpoint to get a JWT.

  1. Decide the client id. This could be the service name foo, or a random value. Random value is better but fundamentally this is a public value and not designed to be a secret so it doesn't matter too much.
  2. Generate a Client Secret and add it as a secret to the swarm. The secret should be named using the convention oauth-clientsecret-[ClientId]. You can use open ssl to generate the secret value and add it as a docker secret in one go as shown below:
> openssl rand -hex 32 | docker secret create oauth-clientsecret-foo -
  1. Map the secret to the Authentication Server service, as well as the microservice that needs to send it.
 docker service update --secret-add oauth-clientsecret-foo foo
 docker service update --secret-add oauth-clientsecret-foo auth-server

The team developing foo should make sure they mount the secret

version: "3.1"

services:

  foo:
    image: myrepo/foo:${TAG:-latest}
    ports:
      - 80:80
      - 443:443
    networks:
      - gateway
    environment:
      - OAUTHCLIENTID=foo
    secrets:
      - oauth-clientsecret-foo
    deploy:
      replicas: 3

secrets:
  oauth-clientsecret-foo:
    external: true

That's it. The application can now send the CLIENTID and the client secret (which is made available within the container as a file in a secrets directory by default unless they mount it somewhere else) in exchanged for a signed JWT token which it can use to authenticate with other services.

Mapping custom claims

By default, the signed JWT token that is issued, will only contain minimal claims, including the ClientId and a few other things. If you want to map additional claims, you have to configure them via config:

```json 
{
   "Foo":{
        "Claims":[
           { "Name" : "Foo", "Type": "Bar", "Value": "Baz" }
        ]
    }
}
```