2022-07-30 Production Ready GraphQL

[jordan-choi]

Authorization

📘 Authentication vs Authorization

• Authentication: 유저가 누구인지, 로그인 여부를 정하는 행위
• Authorization: 유저가 특정 리소스에 접근할 수 있는지를 결정하는 행위

• GraphQL 단계에서 authorization 로직을 포함하는 것을 추천하지 않는다. GraphQL은 보통 도메인 로직에 접근하는 한 방법일 뿐이다.
• authroization은 어떤 필드나 타입에 유저가 접근 가능한지 정하는 API scopes와 도메인과 관련된 authorization이 있다.
• API scopes는 GraphQL 레이어에 구현하면 좋으나, 도메인과 관련된 비즈니스 규칙은 최대한 GraphQL 로직과 분리되어야 한다.
• GraphQL 레이어에 authorization을 구현할 때 고려할 사항은 다음과 같다:
  • 필드마다(per-field) authroization 규칙을 적용하는 것보다 타입마다(per-type) 규칙을 적용하는 것을 추천한다.
    • 객체 타입이 API scopes에 잘 맞는다.
    • 객체에 접근하는 모든 경로를 추적하는 것은 어렵다; 필드 레벨로 체크하면 예상하지 못한 접근 패턴에 노출될 수 있다.

    type Query {
      adminThings: AdminOnlyType!
        @authorization(scopes: ["read:admin_only_types"])
      product: Product!
        @authorization(scopes: ["read:products"])
    }
    
    type Product {
      name: String
      settings: AdminOnlyType!
    }

• Leaking Existence
  • API authroization에서 흔히 발생하는 문제는 다음 두 가지의 미묘한 차이점이다: 너가 찾고 있는 이건 존재하지만 넌 못 봐 vs 너가 찾는 건 없어 (사실 있지만 너한테 안 알려줌)
  • 이 문제를 해결하기 위해 우리는 에러를 리턴하는 대신 간단하게 null을 리턴할 수 있다. 2장에서 말했던 “필드를 non-nullable로 만들기 전에 두 번 생각해”라고 말했던 이유 중 하나다.

Blocking Introspection

📘 Introspection (스키마 확인)
GraphQL에서 스키마가 어떤 쿼리를 지원하는지에 대한 정보를 요청할 수 있는 (GraphQL에서 제공하는) 기능.

• Introspection은 end users가 아닌 개발자를 위한 툴이다. 즉, development 환경에서는 사용 가능해야겠지만 production 환경에서 열어둘 필요는 없다 (특히 internal API).
  • 읽어보면 좋은 글: Why You Should Disable GraphQL Introspection In Production – GraphQL Security
• Public GraphQL API의 경우, 이미 schema가 노출되어있기 때문에 introspection을 제한할 필요가 없다.

Persisted Queries

• 클라이언트가 서버에 쿼리를 보내면, 서버는 다음의 과정을 실행한다:
  1. lex
  2. parse
  3. validate
  4. execute the query

  📘 lexer vs parser

  • lexer: input stream을 token으로 분리하고 (tokenizer), 각 token에 추가 정보를 붙임 (토큰의 의미를 분석하는 역할).
  • parser: lexer가 토큰 단위로 키워드나 속성을 정의한 결과를 구조적으로 나타냄(parse tree를 구축).

• 문제: 클라이언트가 보내는 query string은 동일한데 위 과정을 반복한다면 낭비다.
• full query document를 매 요청마다 보내는 대신, 클라이언트는 서버에 쿼리를 등록한다.
• 다음 예시는 첫번째 쿼리를 등록용으로 사용하는 방법이다.
  1. 클라이언트가 첫번째 쿼리를 보낸다.
  2. 서버가 해당 쿼리에 대한 ID를 보낸다.
  3. 다음 요청부터 쿼리 ID를 서버에 보낸다.
• 장점은 다음과 같다:
  • 클라이언트가 매번 full query string을 보낼 필요가 없다; bandwidth 절약 가능.
  • 서버가 해당 쿼리에 대해 최적화할 수 있다.

Summary

• 객체 타입을 인가하는 것(authorizing object types)이 필드를 인가하는 것(authorizing fields)보다 보통 더 간단하고 에러를 덜 일으키는 경향이 있다.
• introspection을 금지하는 것은 private API에는 좋은 생각이지만 public API에서는 되도록 하지 말하야 한다.
• persisted quries는 굉장히 강력한 개념이다 (특히 internal API에).