# Authorization via OIDC and OAuth 2.0 [OAuth 2.0][3] is a framework for Authz and can be extended [OpenID Connect][4] for Authn. ```plaintext OAuth 2.0 Protocol Flow +--------+ +---------------+ | |--(A)- Authorization Request ->| Resource | | | | Owner | | |<-(B)-- Authorization Grant ---| | | | +---------------+ | | | | +---------------+ | |--(C)-- Authorization Grant -->| Authorization | | Client | | Server | | |<-(D)----- Access Token -------| | | | +---------------+ | | | | +---------------+ | |--(E)----- Access Token ------>| Resource | | | | Server | | |<-(F)--- Protected Resource ---| | +--------+ +---------------+ ``` ```plaintext OIDC Protocol Flow +--------+ +--------+ | | | | | |---------(1) AuthN Request-------->| | | | | | | | +--------+ | | | | | | | | | | | End- |<--(2) AuthN & AuthZ-->| | | | | User | | | | RP | | | | OP | | | +--------+ | | | | | | | |<--------(3) AuthN Response--------| | | | | | | |---------(4) UserInfo Request----->| | | | | | | |<--------(5) UserInfo Response-----| | | | | | +--------+ +--------+ ``` The IDToken is a [JWT][5] with the standard claims. The `scope` claim includes a space delimited list of permissions that the current subject is entitled to. For example: ```json { "sub": "", "aud": "https://api.cmdzero.io", "iss": "https://auth0.com", "exp": "unix-timestamp-expires-at", "iat": "unix-timestamp-issued-at" "scope": "write:groups read:incident", } ``` If an `IDToken` is provided as part of an OpenID Connect transaction then this token can be used to fetch any profile information update from the OpenID user profile endpoint to stay in sync with any profile changes that occur. All Authz permissions (claims) for a given Principal (Resource Owner) can be included in a stateless Access Token that can be used to access a REST API (Resource Server). The API can check the validity of a token and its permissions by checking the disposition of the provided token against the [token introspection endpoint][1] and/or it can verify the signature of the token if the Access Token is a [JWT][5] Request: ```plaintext POST /introspect HTTP/1.1 Host: auth0.com Accept: application/json Content-Type: application/json { "token": "mF_9.B5f-4.1JqM", "token_type_hint": "access_token" } ``` Response: ``` HTTP/1.1 200 OK Content-Type: application/json { "active": true, "sub": "", "aud": "https://api.cmdzero.io", "iss": "https://auth0.com", "exp": "unix-timestamp-expires-at", "iat": "unix-timestamp-issued-at" "scope": "write:groups", } ``` ## API Gateway Example Flow ```plaintext ||======================================================|| || || || VPC || || || --------------- || --------------------- ------- --------- --------- || ------ | Client (RP) | || | API Gateway (PEP) | | PDP | | API A | | API B | || | OP | --------------- || --------------------- ------- --------- --------- || ------ | || | | | | || | | GET /login | | | | || | |----------------------------------------------------------------||-->| | || | | | | || | | ... || | | ... || | |<---------------------------------------------------------------||---| | || return access_token: "x.y.z" | | || | | || | | | | || | | GET /my/organizations | | | | || | | Authorization: "x.y.z"| | | | || | |---------------------->| | | | || | | || | | | | || | | || |------------>| | | || | | || | | | | || | | || |<------------| | | || | | || | Allow | | | || | | || | | | | || | | || |---------------------->| | || | | || | | | | || | | || |<----------------------| | || | | || | | | | || | |<----------------------| | | | || | | || | | | | || | | || | | | | || | | GET /my/notifications | | | | || | | Authorization: "x.y.z"| | | | || | |---------------------->| | | | || | | || | | | | || | | || |------------>| | | || | | || | | | | || | | || |<------------| | | || | | || | Allow | | | || | | || | | | | || | | || |--------------------------------->| || | | || | | | | || | | || |<---------------------------------| || | | || | | | | || | |<----------------------| | | | || | | || | | | | || | | DELETE /admin/users | | | | || | | Authorization: "x.y.z"| | | | || | |---------------------->| | | | || | | || | | | | || | | || |------------>| | | || | | || | | | | || | | || |<------------| | | || | | || | Deny | | | || | |<----------------------| | | | || | | || | | | | || | | || || | | ||======================================================|| | ``` [Auth0][2] can be used as the OP in the diagram above. ## Microservices Security in Action * https://learning.oreilly.com/library/view/microservices-security-in/9781617295959/ * TLS Bridging: proxy server terminates TLS for incoming connection and creates a new TLS connection to the destination of the message. * TLS Tunneling creates a tunnel between the client and the microservices. The API gateway terminates all client connections at the edge. It dispatches requests to the upstream service if all looks good. The initial client/user context needs to be passed through as well. Service to Server authn 1. Trust the network 1. Mutual TLS 1. JSON Web Tokens Service-level authz 1. centalized PDP 1. embedded PDP Propagating User Context 1. Send user context as an HTTP Header 1. Use a self signed JWT 1. Use a JWT issued by a trusted external STS ```plaintext ---------- | Client | ---------- | ||=====================|========================|| || V || || |--------------| || || | API Gateway | || || |--------------| || || | || || ----<----| || || | || || *******V********* ******************* || || * | |----->---------------- * || || * | | * * | * || || * V | * * V * || || * ========= * * --------- * || || * | |<----<-----| * | | * || || * | API A | * | * | API B | * || || * | |----->--| | * | | * || || * ========= * | | * --------- * || || * | A * | | * * || || * V | * V |-<-----<-----| * || || * | ------- * | * ------- * || || * |->| STS | * |---->------->| STS | * || || * ------- * * ------- * || || ***************** ******************* || || || ||=====================|========================|| ``` * The API Gateway pattern is used to expose microservices to client applications as APIs. * The API gateway helps to expose microservices of different flavors by using a consistent and easy-to-understand interface to the consumers of these services. * Protocols such as basic authn and mTLS are not sufficient to secure API's. * An access token can be a reference token or a self-contained token (JWT). If it is a reference token, the gateway has to talk to the issuer to validate it. * Self contained tokens need short TTL's mitigate token revocation. ### Same Origin Policy Cross origin resource sharing (CORS) is the exception to the same-origin policy. It allows an app running on `localhost:4200` to access resources on `localhost:8080`. Web browsers use the `OPTIONS` HTTP method along with special HTTP headers to determine whether to allow or deny a cross-origin request. Before sending a request to a different origin the browser will send an HTTP `OPTIONS` request to the resource on the particular origin. This is known as a _preflight request_. The request includes the following HTTP headers: * `Access-Control-Request-Headers`: indicates the HTTP headers that the request is about to send to the server. * `Access-Control-Request-Method`: indicates the HTTP method about to be executed by the request (e.g. `GET`). * `Origin`: indicates the origin of the web application. (e.g. `http://localhost:4200`) The server responds to the preflight request with the following headers: * `Access-Control-Allow-Credentials`: indicates whether the server allows the request originator to send credentials in the form of authorization headers, cookies, or TLS client certificates. (e.g. `true` or `false`) * `Access-Control-Allow-Headers`: indicates the list of headers allowed by the particular resource on the server. * `Access-Control-Allow-Methods`: indicates the list of HTTP methods allowed by the particular resource on the server. * `Access-Control-Allow-Origin`: indicates the cross-origin allowed by the server. * `Access-Control-Max-Age`: indicates for how long to cache the preflight request. ## Glossary * PAP: Policy Administration Point. * PEP: Policy Enforcement Point is a gateway that protects all requests routed to this point to make a decision. It takes the incoming HTTP request and creates an authz specific request. Usually this is the API Gateway. * PDP: Policy Decision Point consumes an authz request send from the PEP to make a decision on whether to allow or deny the request. * RP: Relying Party is the OAuth 2.0 Client application. * OP: OpenID Provider is the OAuth 2.0 Authorization Server that is capable of Authn and providing claims to a RP about the authn event and User. * STS: Security Token Service * `X-Forwarded-For` HTTP header field is a common method for identifying the originating IP address of a client connecting to a web server through an HTTP proxy or load balancer. [1]: https://datatracker.ietf.org/doc/html/rfc7662#section-2 [2]: https://auth0.com/docs/authenticate/login/oidc-conformant-authentication/oidc-adoption-access-tokens [3]: https://datatracker.ietf.org/doc/html/rfc6749 [4]: https://openid.net/specs/openid-connect-core-1_0.html#Overview [5]: https://datatracker.ietf.org/doc/html/rfc7519