인증(Authentication) 전략

JISEUNG·2023년 2월 26일

Frontend-Roadmap

목록 보기

10/15

인증(Authentication) 전략은 보호된 리소스에 대한 액세스 권한을 부여하기 위해 사용자 또는 시스템의 신원을 확인하는 데 사용되는 방법 또는 기술이다.
인증이 무엇이며 어떻게 작동하는지 알고 애플리케이션에 대한 인증 전략을 선택할 때 더 나은 결정을 내려보자.

Basic Authentication

HTTP를 통해 리소스에 접근하기 위한 인증 방법으로, credentials가 요청 헤더로 전달되는 방식이다.

API에서도 사용할 수 있으며, 이 경우에는 token based Authentication과 유사하다.

TLS/HTTPS와 사용하지 않으면 누구나 credentials를 디코딩할 수 있기 때문에 안전하지 않다.

How does it work?

클라이언트가 보호된 URL에 접근한다.
서버는 요청이 Authorization헤더가 올바른 credentials를 가지고 있는지 확인해 응답한다.
- 200 (OK)
- 401 (Unauthorized)
- 이때, WWW-Authenticate: Basic realm="..."와 같은 응답을 포함하는데, 여기서 realm은 같은 credentials가 필요한 보호된 페이지들의 집합을 말한다. 브라우저는 realm을 통해 유효한 credentials를 캐시해두고 사용할 수 있다.
401 응답을 받으면 브라우저는 응답 헤더에서 WWW-Authenticate 를 확인하고, 화면에 credentials에 대한 경고를 표시한다.
유저는 credentials(username, password, ...)를 제출한다. 브라우저는 credentials를 base64로 인코딩해서 다음 요청에 보낸다. creadentials는 Authorization헤더에 담겨 보내진다.
- ex. Authorization: Basic ...
2단계로 돌아가서 다시 인증을 수행한다.

Session Based Authentication

유저가 유니크한 identifier에 배정된다. identifier는 서버 메모리에 저장된다. 이 identifier를 session이라고 한다.

클라이언트는 session id를 모든 요청에 담아 보낸다. 서버는 이것으로 유저를 식별한다.

stateful한 인증 방법이다.

인증에서의 Stateful vs Stateless

stateful : 세션 인증을 철회할 수 있다.
stateless : 세션 인증을 철회할 수 없다.

How does it work?

서버는 계속해서 메모리(저장소)에 있는 로그인 유저들을 추적한다.

클라이언트가 로그인 요청을 보낸다.
서버는 credentials를 검증하고, session을 생성해 현재 유저에게 배정된 메모리에 저장한다.
그리고 session id를 생성해 응답해준다.
클라이언트는 session id를 받아 쿠키나 로컬/세션 스토리지에 저장한다.
클라이언트는 다음 요청을 session id와 함께 보낸다. 서버는 저장소에 현재 session id의 유저가 있는지 확인하고 응답한다.
- 200 (OK)
- 401 (Unauthorized)
유저가 로그아웃하면 서버는 세션을 삭제한다. 동일한 session id는 재사용할 수 없다.

Token Based Authentication

요청마다 credentials(username, password)를 보내는 Basic Auth 방식과 다르게, 매 요청에서 토큰(token)을 보내는 방식이다.

Token

서버에서 생성한 문자열. 클라이언트가 요청에 사용할 수 있다.
서버가 저장하지 않는다. (Stateless)
시간이 지나면 만료될 수 있다.
암호로 서명되어 변조를 식별할 수 있으므로 서버에서 신뢰할 수 있다.
일반적으로 Authorization header로 보낸다.
불투명성 : 의미없는 랜덤 문자열. 인증 서버에 의해서만 확인 가능하다.
self-contained : 토큰이 데이터를 가지고 있고, 클라이언트가 볼 수 있다. (e.g. JWT Tokens)

How does it work?

클라이언트는 토큰을 생성하기 위한 credentials를 서버에 보낸다.
서버는 credentials를 검증하고 응답한다.
- 200 (OK) : body나 header를 통해 토큰을 보내준다.
- 422 (Unprocessable Entity)
클라이언트는 토큰을 로컬 스토리지나 쿠키에 저장하고, 차후 요청에 보낸다.
서버는 토큰을 검증하고, 토큰이 유효한지 응답한다.
- 200 (OK)
- 401 (Unauthorized)

Examples

SWT (Simple Web Tokens)
JWT (JSON Web Tokens)
OAuth (Open Authorization)
SAML (Security Assertions Markup Language)
OpenID

JWT(JSON Web Token) Authentication

Token Based 인증 방식의 하나로 Open Standard(RFC 7519)에 기반한다.
인증과 안전한 정보 교환에 사용된다.

How does it work?

다른 토큰 인증 방식처럼 구분자(diffrentiator)만이 토큰이 생성된 방식을 알 수 있다.

클라이언트는 유저의 credentials를 서버로 보내 토큰 발급을 요청한다.
서버에서 credentials를 검증한다.
서버는 secret key를 사용해 JWT(JSON Web Token)을 생성한다.
생성한 JWT를 클라이언트에 보내준다.
클라이언트는 보호된 endpoint에 접근할 때 JWT를 요청 헤더에 포함한다.
서버는 secret key를 사용해 JWT를 검증한다.
검증된 JWT라면 클라이언트의 리소스 요청에 응답한다.

JWT Token

URL-Safe 문자열. header/body 혹은 URL을 통해 서버로 전달된다.
토큰은 데이터를 포함할 수 있는 등 self-contained. 누구나 볼 수 있다.
다음 세가지 파트로 이루어져 있다.
- XXX.YYY.ZZZ (X: header, Y: payload, Z: signature)
- X(header) : base64로 생성된 문자열. 토큰의 메타정보(토큰의 종류, 해싱 알고리즘)를 포함한다.
- Y(payload) : base64로 생성된 문자열. 토큰에 포함시키고 싶은 데이터가 여기 있다.
- Z(signature) : header/payload를 해싱하는 문자열. 서버가 signature를 통해 토큰을 확인한다.
토큰 payload에 담긴 데이터를 claims라고 한다.

3 types of Claims

Public Claims

userId, email 등 사용자 정의 claims

Private Claims

토큰의 공급자, 소유자 이외에게 의미없는 claims

Registerd Claims

예약된 claims

iat : issued at
iss : issuer
sub : token subject
exp : expiry time
aud : token audience
nbf : not before
jti : unique token identifier

OAuth(Open Authorization)

유저가 서드파티에 개인정보 공유를 허용하는 오픈 프로토콜 인증 전략

Third party

프론트엔드에서 API로부터 인증하는 방식
- 커스텀 OAuth 서버에서 OAuth 인증
타 서비스로 로그인하는 방식
- 타 OAuth 서버에서 OAuth 인증

Versions

OAuth 1.0 (deprecated)
OAuth 2.0 (Active, Not backward compatible)
OAuth 2.1 (draft)

How does it work?

4가지 인증 플로우(허가 방식)가 있다.
모든 플로우에서 클라이언트는 토큰으로 보호된 리소스에 접근한다.

1. Authorization Code Grant Flow

클라이언트가 토큰을 요청한다.
인증 서버는 클라이언트를 검증하고 유저에게 로그인 양식을 제공한다.
유저는 로그인 양식을 통해 인증 서버에게 로그인을 요청한다.
인증 서버는 유저의 credentials를 검증하고, 유저가 공개할 정보의 범위를 물어본다.
유저는 인증 서버의 범위에 대한 정보 접근을 허용한다.
인증 서버는 클라이언트에게 인증 코드와 리다이렉트 URI를 준다.
- Redirect URI : 로그인 성공 후 인증 코드와 함께 리다이렉트 될 URL
클라이언트는 인증 코드, 유저 정보로 인증 서버에게 토큰을 요청한다.
- 이 단계는 보안이 필요하므로 서버사이드에서 이루어져야 한다.
인증 서버는 검증 후 클라이언트에게 토큰을 준다.
클라이언트는 토큰을 통해 보호된 리소스에 접근하고 응답받는다.

Query Params in Token Request

{
  client_id: [client_id],
  response_type: code,
  scope: [scopes],
  redirect_uri: [redirect_uri],
  state: [redirect_uri]
}

2. Implicit Grant Flow

Authorization Code Grant Flow와 비슷하다.
6단계에서 인증 서버로부터 인증 코드가 아닌 토큰을 받는다. 7, 8단계가 불필요하며, 받은 토큰으로 바로 보호된 리소스에 접근하고 응답받는다.

Query Params in Token Request

{
  client_id: [client_id],
  response_type: token,
  scope: [scopes],
  redirect_uri: [redirect_uri],
  state: [redirect_uri]
}

3. Client Credential Grant Flow

Authorization Code Grant Flow와 비슷하다.
Implicit Grant Flow처럼 토큰을 받는다.
유저와의 인터랙션이 없다. 앞의 단계를 다 건너뛰고 7단계부터 바로 시작한다.(인증 코드 없이)

Query Params in Token Request

{
  client_id: [client_id],
  response_type: token,
  scope: [scopes],
  redirect_uri: [redirect_uri],
  state: [redirect_uri],
  grant_type: [token]
}

4. Password Grant Flow

Authorization Code Grant Flow와 비슷하다.
인증 서버에 바로 유저의 credentials를 제출한다.
즉, 3-6단계를 건너뛰고 7단계로 넘어가며 credentials는 바로 인증 서버로 제출된다.

Query Params in Token Request

{
  client_id: [client_id],
  response_type: token,
  scope: [scopes],
  redirect_uri: [redirect_uri],
  state: [redirect_uri],
  grant_type: [password]
}

Token, Expiry date, Refresh Token

위 플로우들에서 응답된 Token은 보통 만료 기한과 Refresh Token을 동반한다.
Token이 만료되면 Refresh Token로 갱신한다.

SSO(Single Sign-On)

여러 독립적인 서비스들에서 유저가 단일한 username, password로 로그인하게 해주는 전략
ex. Gmail 로그인으로 모든 google product 이용
SSO가 없다면 구글의 모든 서비스에 각각의 credentials로 로그인해야한다.

SAML (Security Assertion Markup Language)

관계자(party) 간 인증, 인증 정보를 교환하는 Open Standard

3 parties involved in SSO or SAML implements

User : 리소스에 접근하고자 하는 주체
Identity Provider(IDP) : 어떤 유저가 있고, 유저가 무엇을 할 수 있는지
- 유저를 인증한다.
- SAML assertion을 생성한다.
- SAML assertion을 SP들에게 보낸다.
Service Provider(SP) : 어떤 접근을 허용할지
- SAML assertion를 확인해서 검증된 유저에게 접근을 허용해준다.
- 검증되지 않은 유저는 IDP로 보내서 로그인하고 오게 한다.

SAML assertion

XML 문서
- 인증 정보를 포함하며, 신뢰할 수 있게 서명된다.
- SAML assertion의 형식과 content는 SP와 IDP 사이에서 합의되어 있다.
- 메타 데이터 파일이 IDP, SP에 존재한다.
Configuration: 필요한 자원 정보
Certificates: assertion을 검증해줌으로써 데이터가 신뢰할 수 있음을 보장한다.

How does it work?

1. Identity Provider Initiated Flow

클라이언트가 IDP에게 인증 요청

유저가 IDP에게 요청을 시작한다.
IDP는 유저에게 인증을 요구한다.
유저는 IDP에게 credentials를 보낸다.
IDP는 credentials가 검증되지 않으면 reject하고, 검증되면 SAML assertion을 보내준다.
IDP에게 받은 SAML assertion을 SP에 보낸다.
SP는 SAML assertion을 검증하고, 검증되면 세션이 시작된다.

2. Service Provider Initiated FLow

클라이언트가 SP에게 인증 요청

Identity Provider Initiated Flow와 같지만, 첫번째 요청이 SP로부터 온다.
즉, SP가 먼저 유저를 IDP에서 인증하도록 한다.

Reference

Basic Authentication
Session Based Authentication
Token Based Authentication
JWT Authentication
OAuth
SSO - Single Sign On

JISEUNG

Frontend Web Developer

이전 포스트

렌더링 패턴

다음 포스트

인증(Authentication) 전략

Frontend-Roadmap

Basic Authentication

How does it work?

Session Based Authentication

인증에서의 Stateful vs Stateless

How does it work?

Token Based Authentication

Token

How does it work?

Examples

JWT(JSON Web Token) Authentication

How does it work?

JWT Token

3 types of Claims

Public Claims

Private Claims

Registerd Claims

OAuth(Open Authorization)

Third party

Versions

How does it work?

1. Authorization Code Grant Flow

Query Params in Token Request

2. Implicit Grant Flow

Query Params in Token Request

3. Client Credential Grant Flow

Query Params in Token Request

4. Password Grant Flow

Query Params in Token Request

Token, Expiry date, Refresh Token

SSO(Single Sign-On)

SAML (Security Assertion Markup Language)

3 parties involved in SSO or SAML implements

SAML assertion

How does it work?

1. Identity Provider Initiated Flow

2. Service Provider Initiated FLow

Reference

렌더링 패턴

우리는 웹 접근성과 친해져야 합니다.

0개의 댓글