Home
About
- Zzu-h
  
  주니어 Android 개발자입니다.
- Learn More
- Email
- Instagram
- Tistory
- Github
Posts
Projects

Android: 사용자 인증

10 May 2022

Reading time ~3 minutes

oAuth 2.0

인증을 위한 오픈 스탠다드 프로토콜
사용자가 Facebook이나 트위터 같은 인터넷 서비스의 기능을 다른 애플리케이션(데스크톱, 웹, 모바일 등)에서도 사용할 수 있게 한 것
외부 어플리케이션은 사용자 인증을 위해 Facebook과 Apple 및 Google의 등의 사용자 인증 방식을 사용한다.
- 이 때, oAuth를 바탕으로 제 3자 서비스는 외부 서비스(Facebook, Apple, Google)의 특정 자원을 접근 및 사용할 수 있는 권한을 인가받게 된다.
oAuth 1.0에서 잘 설명하고 있다.

oAuth 참여자

Resource Server
- Client가 제어할 자원을 보유한 서버
Resource Owner
- 자원의 소유자
Client
- Resource Server에 접속하고 정보를 가져오는 유저

oAuth Flow

Client 등록
- Client가 서버를 이용하기 위해서 자신의 서비스를 등록해야함
- 등록을 통해 다음의 3가지 정보를 제공받는다.
  1. Client ID
    - 클라이언트 식별자
  2. Client Secret
    - Client ID에 대한 비밀키
  3. Authorized redirect URL
    - Authorization Code를 전달 받을 리다이렉트 url
- 외부 서비스를 통해 인증을 마치면 클라이언트를 Redirect URL로 연결시킴
  - 이때, Query String으로 Code가 함께 전달됨
- 클라이언트는 Resource Server를 통해 자원을 이용할 수 있는 Access Token을 발급받는다.
Resource Owner의 승인
- Client 어플리케이션을 사용하다 소셜 로그인 버튼을 클릭 후
  - Resource Owner는 Server에 접속하여 로그인을 수행함
- 로그인이 후
  - Resource Server는 Query String으로 넘어온 파라미터로 Client를 검사함
- 검증이 된 후
  - Resource Server는 Owner에게 해당하는 권한을 부여할 것인지 물어봄
- Resource Owner가 Resource Server에게 Client의 접근을 승인
Resource Server의 승인
- Owner의 승인 후 명시된 Redirect URL로 클라이언트를 리다이렉트 시킨다.
  - 이 때, Access Token을 발급하기 전 Authorization Code를 함께 발급함
- Client는 ID, 비밀키, Code를 Resource Server에 직접 전달함
- Server는 정보를 검사하고, 유효한 요청이라면 Access Token을 발급한다.
API 호출
- 발급받은 Token을 헤더에 담아 API를 요청하면 Server의 자원을 이용할 수 있음
Refresh Token
- Access Token은 만료기간이 있음
  - 만료기간이 되어 Token을 새로 발급하는 것은 번거로운 일
  - 만료된 Token을 이용하면 401에러를 발생시킴
- Resource Server는 Access Token을 발급할 때 Refresh Token을 함께 발급함
- Client는 두 Token을 모두 저장
- 401 에러가 발생되었을 때 Refresh Token을 활용해서 새 Access Token을 발급받음

Cookie

하이퍼 텍스트의 기록서(HTTP)의 일종
인터넷 사용자가 어떠한 웹사이트를 방문할 경우 그 사이트가 사용하고 있는 서버를 통해 인터넷 사용자의 컴퓨터에 설치되는 작은 기록 정보 파일

HTTP 특성

HTTP는 인터넷 상에서 데이터를 주고 받기 위한 서버/클라이언트 모델을 따르는 프로토콜
비연결지향
- 클라이언트가 요청을 서버에 보내면, 서버는 적절한 응답을 주고 연결을 끊는다.
  - 서버가 다수의 클라이언트와 연결을 유지한다면, 이에 따른 자원 낭비가 극심
상태 없음
- 클라이언트에 대한 이전 상태 정보 및 현재 통신 상태가 없음

이는 자원을 아낄 수 있는 장점이 있으나 로그인을 하더라도 다음 요청에서는 클라이언트를 기억하지 못하기에 인증을 다시해야하는 단점이 있음

Cookie 등장

쿠키는 HTTP 장점이자 단점을 보완하기 위해 등장함
쿠키: 클라이언트 로컬에 저장되는 Key-Value 작은 데이터 파일
- 서버에서 HTTP Response Header에 Set-Cookie 속성을 이용하여 클라이언트에게 쿠키를 제공함
쿠키는 다음의 정보를 가지고 있다.
- 이름
- 값
- 만료 날짜/시간
- 경로 정보 등

세션 쿠키와 지속 쿠키

세션 쿠키
- 브라우저 메모리에 저장되며, 브라우저가 종료될 때 쿠키도 같이 사라진다.
- 만료 날짜/시간을 지정하지 않으면
  - ‘메모리에 있는 동안 유지’로 판단
  - 세션쿠키로 저장됨
- 브라우저 메모리에 저장되기에 보안에 유리함
지속 쿠키
- 파일로 저장됨
- 만료 날짜/시간을 지정하게 되면
  - 시간이 될때까지 유효하므로 파일로 저장됨
- 따라서 프로세스가 종료되더라도 이 쿠키는 지속된다.
- 하지만 파일로 저장되기에 보안에 비교적 취약하다.

Cookie Flow

브라우저에서 웹페이지에 접속
클라이언트가 요청한 웹페이지를 응답으로 받음
- HTTP 헤더를 통해 해당 서버에서 제공하는 쿠키 값을 응답으로 줌
- 클라이언트가 해당 쿠키를 저장
클라이언트가 웹페이지를 요청한 서버에 재 요청시 받았던 쿠키 정보를 HTTP 헤더에 담아서 요청
서버는 그 요청에서 쿠키 값을 참고하여 적합한 요청에 대한 응답을 함

JWT

클라이언트와 서버, 서비스와 서비스 사이 통신 시 권한 인가를 위해 사용하는 토큰

구조

JWT는 ‘.’을 구분자로 세 부분으로 된 문자열로 이루어져 있다.
Header
- JWT를 어떻게 검증하는가에 대한 내용을 담는다.
- JWT를 검증하는데 필요한 정보를 가진 JSON 객체는 URL-Safe로 인코딩된 문자열
  - alg
    - 서명 시 사용하는 알고리즘
  - kid
    - 서명 시 사용하는 키를 식별하는 값
- 위 JSON 객체를 문자열로 직렬화 하여 인코딩해서 도출된 결과값을 담는다.
Payload
- JWT의 내용
- Payload에 있는 속성들을 Claim Set이라 부른다.
  - JWT에 대한 내용이나 클라이언트와 서버 간 주고 받기로 한 값들로 구성
Signature
- 헤더와 페이로드를 합친 문자열을 서명한 값
- 서명은 허데의 alg에 정의된 알고리즘과 비밀 키를 이용해 생성 후 인코딩

장점과 단점

장점
- 세션방식과 다르게 별도의 인증 저장소가 필요 없음
  - 서버와의 통신을 최소한으로 할 수 있음
- 트래픽에 대한 부담이 줄어듬
단점
- 크기가 커질수록 데이터 트래픽 크기에 영향을 줄 수 있음
- 클라이언트에 저장되기에 DB에서 사용자 정보를 수정하더라도 토큰에 직접 적용할 수 없음

JWT와 oAuth

oAuth는 위에서 정의했듯 하나의 프로토콜이다.
- 하나의 규약이며 이를 통해 보안상의 문제를 해결할 수 잇다.
JWT는 값을 가지는 토큰이다.
- oAuth를 통해 나오는 토큰으로 이를 가질 수 있으며, oAuth와 비교를 하기에는 의미가 다르다.