19.02.14 목요일

D+29

흑,,,힘들오~!

1. OAuth 정리 다시하기 + flow 고치기

2. OAuth 부분 ppt

3. firebase가 OAuth server로 사용할 수 있는지 다시 정리하기

4. JWT와 OAuth의 차이는?

[REST 아키텍쳐, JWT, OAuth, SPA]

REST 아키텍쳐는 범용 API에 쓰이는 서버를 구축할 때 쓰인다. client와 server구조에서 서버를 구현할 수 있는 아키텍쳐의 한 종류이다. 특징은 범용성, 리소스 중심의 API, stateless이며, data를 서버에서 관리하지 않으며 요청 데이터 그 자체를 해석해 응답하므로 서버에서 client를 관리하지 않는다.

1. 그래서 API KEY를 사용한다. 서버측에서 무작위 키를 만들어 놓고 client가 API를 호출할 때마다 HTTP헤더의 특정 필드와 쿼리스트링을 통해 전달한다. 그렇기 때문에 KEY가 노출되면 안된다.

2. API KEY방식은 서비스 제공자가 인터넷에서 서비스를 공개적으로 확장하기에는 충분하지 않다. 그래서 OAuth 프로토콜이 등장하였다. 또한 SSO(통합 인증 서비스)를 구축하는데에 OAuth가 사용된다.

3. API KEY와 OAuth는 토큰이 유효한 지 일일이 확인해야 한다. 이는 서버에서 토큰의 유효성(client 관리)을 관리해야 한다는 의미이고 API를 호출할 때마다 데이터 베이스를 확인해야 한다. 그래서 JWT를 사용한다(Base 64 사용).

firebase의 인증(Authentication)

firebase Authentication은 인증을 쉽게 할 수 있도록 도와준다. 오직 클라이언트 사이드의 코드로 유저 인증과 로그인 서버를 통합한다. custom, email&password, anonymous, facebook, google, twitter, github 사용자 인증 기능을 제공한다.

* 클라이언트 사이드

네트워크의 한 방식인 클라이언트-서버 구조의 클라이언트 쪽에서 행해지는 처리를 말한다.

OAuth2.0의 4가지 인증방식

1. Password Grant Type

• 구글에 로그인하기, 구글 앱(자사 앱)에 로그인하기

• 유저(owner)가 앱에서 api서버에 ID와 password를 직접 전달해서 액세스 토큰을 받고 자원을 조회한다.

2. Authorization Code Grant Type

• client에 구글로 로그인 하기, 구글 프로필/사진 가져오기 등

• 유저가 로그인하고 권한을 위임한 뒤 authorization code를 포함한 콜백 uri로 리디렉션한다.

• 이 코드를 통해 access token을 부여받고 구글에서 정보를 가져올 수 있다.

3. Implicit Grant Type

• 구글 프로필/사진 가져오기

• code grant는 secret을 https에 노출시키지만 implicit은 노출시키지 않는다. 또한 implicit은 api서버로 시크릿을 보내지 않는다. #해시를 통해 리디렉션 시킨다.

• refresh 토큰을 발급하지 않는다. 암호화가 없으니 user-agent 내에서의 보안을 염두에 두었다.

4. Client Credential Grant Type

• 구글 스스로도 api서버의 유저라고 할 수 있다.

• 앱 아이디와 시크릿을 https로 직접 전달해서 토큰을 받는다.

• 유저가 없다.

OAuth의 네 가지 인증 방식을 각각 어떤 때에 사용하는가

1. Authorization code grant type

• Authorization code grant type은 웹 및 모바일 앱에서 가장 잘 사용된다. Authorization code 부여는 액세스 토큰에 대한 권한 코드를 교환하는 추가 단계가 있으므로 Implicit 유형에는 없는 보안 계층이 추가로 제공된다. 코드 교환 단계는 액세스 토큰이 항상 응용 프로그램과 OAuth서버 사이의 보안 백 채널을 통해 전송되기 때문에 공격자가 액세스 토큰을 가로챌 수 없음을 보장한다.

• 보안 서버에 배포되는 클라이언트이다.

2. Implicit grant Type

• 이 타입은 authorization code grant type처럼 신뢰할 수 있는 콜백 주소를 통해 반환되는 것이 아니라 액세스 토큰을 URL에 직접 반환한다. 액세스 토큰 자체는 브라우저의 기록에 기록되므로 대부분의 서버는 일시적인 액세스 토큰을 발급하여 액세스 토큰이 노출되는 위험을 줄인다. back channel이 없기 때문에 refresh토큰도 없다.

• authorization code grant type은 클라이언트 앱이 인증을 요청할 때 client secret을 https로 보내는데, 이때 서버사이드 앱이나 컴파일 된 앱의 경우에는 시크릿이 노출되지 않지만, javascript어플리케이션에서는 소스 코드 시크릿이 그대로 노출되기 때문에 implicit grant type을 쓰는 것이 적합하다.

• implicit grant type는 인증 요청에서 앱은 api서버로 시크릿을 보내지 않는다. 그냥 앱 아이디와 콜백 url만 보낸다.

• Implicit grant Type는 신뢰할 수 없는 클라이언트에 적합하다. 비밀 정보를 안전하게 저장하는 방법이 없다. 웹 애플리케이션과 같은 사용자 에이전트 기반 클라이언트는 client secret을 안전하게 저장할 수 없다.

3. Client credential Grant Type

• 이 타입은 응용 프로그램 자체가 자원 소유자이고 자체에 대한 액세스 토큰을 요청할 때 사용된다.이 유형에는 사용자가 없다. 이 타입에서 인증권한은 시스템 간 인증에 사용될 수 있다. 어플리케이션이 api를 통해 자체 정보를 업데이트하려고 할 때 사용될 수 있다.