slipway.security.openid.authorization-code-flow — io.factorhouse/slipway-jetty12 2.0.7

access-token clj

(access-token access-token-str)

As this login module is exclusively used in the direct Authorization Code Flow and this access token is intended for use in the same JVM as the ID token, we can rely on the proir ID token validation as being sufficient as they are both from the same source at the same point in time

authenticator clj

(authenticator
  config
  {:slipway.security.openid/keys [oidc-redirect-success oidc-redirect-error
                                  oidc-redirect-logout]
   :or {oidc-redirect-success OpenIdAuthenticator/J_SECURITY_CHECK}})

expiration clj

(expiration id-token
            access-token
            {:slipway.security.openid.jwt/keys [user-expiration-source]
             :or {user-expiration-source :access-token}})

login-module clj

(login-module openid-config opts)

This roles-service is exclusively for OpenID Connect (OIDC) direct Authorization Code flow via the Token endpoint, that is how Jetty implements OIDC authentication interactions. In that flow you can rely on TLS (HTTPS) to authenticate the issuer instead of verifying the JWT signature. While that normally only applies to the ID token, in our case the Access token is intended for local use inside this client service JVM, and so the same logic applies.

roles clj

(roles id-token
       access-token
       {:slipway.security.openid.jwt/keys [user-roles-source user-roles-path]
        :or {user-roles-source :access-token user-roles-path ["roles"]}})

user-state clj

(user-state id-token access-token response opts)

user-state-fn clj

(user-state-fn opts)

username clj

(username id-token
          access-token
          {:slipway.security.openid.jwt/keys [user-id-source user-id-path]
           :or {user-id-source :id-token user-id-path ["sub"]}})