인증과 인가

Authorization 헤더 추가

POST /reviews 연산을 하기 위해 인가된 사용자만 요청할 수 있도록 해당 헤더를 추가한다.

paths:
  /reviews:
    post:
      security:
        - MyUserToken: []
#...
components:
  securitySchemes:
    MyUserToken:
      type: apiKey
      in: header
      name: Authorization

위 코드를 본다면 security내에 기술된 MyUserToken이 securitySchemes내에 기술된 것을 볼 수 있다. 보안 스킴은 보안 요구사항을 설명해주는 역할을 한다.

OpenAPI 3.0.x에서 지원하는 인가 방식

다음과 같은 보안 카테고리를 지원한다.

가장 기본적인 보안 유형은 헤더나 쿼리 파라미터, 쿠키의 값으로 요청을 인가하는 apiKey이다.

components:
  securitySchemes:
    MyUserToken: # 보안 스킴이름
      type: apiKey # 보안 유형
      in: header # apiKey를 사용할 위치, header, cookie, query중 하나를 지정해서 사용할 수 있다.
      name: Authorization # in에서 지정한 헤더, 쿼리, 쿠키의 이름

paths:
  #...
  /reviews:
    post:
      #...
      security: # 연산에 적용할 보안 요구사항을 해당 필드에 정의한다.
        - MyUserToken: [] # 스코프의 리스트를 값으로 갖는 MyUserToken 보안 객체

선택적으로 보안 적용

security 값인 배열에 있는 것중 한 가지만 충족이 돼도 인가받은 요청으로 간주한다. 따라서 아무 내용이 없는 빈 내용을 추가하더라도 인가를 받은 요청으로 간주된다.

paths:
  #...
  /reviews:
    post:
      #...
      security:
        - {} # 빈 객체 추가
        - MyUserToken: []

다른 방식의 보안 스킴

• http: http 방식은 기본 인증 스킴을 적용할 때 사용한다. 기본 인증은 Authorization 헤더를 통해 username과 password를 전달한다. apiKey 방식과 마찬가지로 스코프 개념을 사용하지 않는다.

• oauth2: 인증 위임을 사용하는 OAuth 2.0 프로토콜을 적용할 때 사용한다. 해당 사이트가 아닌 구글이나 페이스북과 같은 다른 서드파티 계정으로 로그인 할 수 있는 웹사이트, 이런 인증 과정이 서드파티에 위임되어 처리하는 것을 OAuth Dance라고 부른다. 이러한 과정에서 사용자 이름이나 이메일 주소를 공유하겠다고 허가하면 사용자 이름이나 이메일 주소가 바로 스코프가 된다. 또한 인증 API 제공자와 사용자 사이의 의사소통이 끝나면 인증 API 제공자는 접근 토큰을 발급해준다. 이 접근 토큰을 헤더에 담아 요청을 보낼 수 있다.

• openIDConnect: OpenID Connect 프로토콜을 적용할 때 사용한다. 탐색 자동화나 사용자 상세 정보를 획득할 수 있는 표준화된 엔드포인트 같은 기능을 추가한 확장판이다.

보안 스킴을 적용하는 일반적인 방법

연산에 인가 기능을 추가하는 일반적인 패턴은 앞에서 봤던 securitySchemes를 기술하고 연산의 security 항목에 기술한 보안 스킴을 사용해 보안 요구사항을 정의하는 것입니다.

해당 항목은 요구사항 객체를 원소로 갖는 배열이며, 스코프는 OAuth 2.0에서만 사용되는 개념이므로 oauth2 방식의 보안 스킴을 사용할 때만 값을 가지며, 그 외의 방식을 적용할 때는 비어 있는 배열을 지정하면 됩니다.