정리_

D+31

* authorization server를 node.js로 구현할 때 필요한 것들 알아보고 공부하기

* 어떻게 구현할 것인지 결정하기

* spring boot로 구현해야 하는 것인가? spring boot와 node.js의 차이는 무엇인가

* passport.js란?

* REST API란?

1. REST API란

Representational State Transfer의 약자이다. 자원을 이름으로 구분하여 해당 자원의 상태를 주고 받는 모든 것을 의미한다.즉, 자원의 표현에 의한 상태 전달을 말한다. REST는 기본적으로 웹의 기존 기술과 HTTP프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일이다.

• 자원의 표현 : 자원(해당 소프트웨어가 관리하는 모든 것)을 표현하기 위한 이름

• 상태 전달 : 데이터가 요청되는 시점에서 자원의 상태를 전달한다. JSON 혹은 XML을 통해 데이터를 주고 받는 것이 일반적이다.

git : 버전관리 프로그램이다. branch 개념으로 저장하고 관리/정리가 된다.

HTTP method : http신호 타입을 분류해 놓은 것을 말한다.

1. get : resource를 보내달라고 server에 요청한다.

2. post : resource를 보내면서 생성해 달라고 server에 요청한다. ex)회원가입하면 DB에 정보를 저장한다.

3. put : resource를 업데이트 하거나 새로운 resource 생성을 요청한다(전체 수정). ex)회원 정보 수정

4. patch : resource를 업데이트 요청한다(부분 수정). ex)회원 정보 수정

5. delete : resource 삭제 요청한다.

express : node.js로 서버 만드는 프레임 워크를 말한다.

req - request에 연관된 함수 값이 저장된 object를 말한다.

ex) HTTP request header, 요청 url, cookies등

res - response에 연관된 함수 값이 저장된 object를 말한다.

ex) HTTP response header, cookies, HTTP code

next - 다음 번 함수를 호출한다.

어떤 페이지 구현할 것인지

로그인/회원가입 화면 구현하기

DB에 정보 저장할 수 있게 구현하기

mySQL/mongoDB사용

mysql설치하기

클라이언트가 서버에 등록하기 위한 필수 요소 세 가지는 client ID, client secret, authorized redirect URIs입니다. 다시 말해, 클라이언트를 google developer와 같은 곳에 등록을 하게 되면 client ID와 client secret을 얻게 됩니다. client ID는 우리가 만든 어플리케이션의 식별자 ID이며, secret은 그에 대한 비밀번호이고, redirectg URIs는 리소스 서버가 권한을 부여하는 과정에서 authorized code라는 것을 전달하는데, 이 코드를 이 URI로 전달합니다.

여기서 user를 Resource Owner라고 하며, 내 서비스를 Client, 다른 서비스를 Resource Server라고 합니다. Client와 Resource Server 사이에 Authorization Server가 있는데, 이는 Client가 Owner에게 허가를 받고 code와 access token을 부여해 주는 서버입니다. 다음 설명에서는 편의상 Resource Server와 Authorization Server를 하나로 통일(Authorization Server)하여 설명하려고 합니다.

1. 먼저 owner가 client에 접근하게 되면, client는 server의 기능이 필요하기 때문에 server에 먼저 로그인해야 된다는 화면을 띄워줍니다. 이때 ‘구글로 로그인’ 버튼의 주소는 [http://서버 주소&scope=b,c&client_ID=1&redirect_uri=리다이렉트 주소]의 형식으로 되어있습니다.

2. owner가 이 버튼을 누르면 server로 접속하게 됩니다. server에 로그인을 성공하게 되면 주소의 client id 값이 server에 등록된 client id값과 동일한지 확인하고, redirect URI도 확인한 후 모두 같으면 client에서 요청한 scope를 제공하는데 동의할 것인지의 여부를 owner에게 묻습니다.

3. owner가 허용하게 되면 허용했다는 메시지를 server에게 전송하고, server가 전송을 받으면 client에서 요청한 기능(scope)를 server에 저장합니다.

4. scope를 server에 저장하고, 정보가 저장된 authorized code를 발급합니다. 이 authorized code를 owner에게 전송하는데, 헤더값으로 [location:https://redirect_uri?authorized_code=3]을 줍니다. 이를 통해 owner를 redirect 시킬 수 있습니다. 이를 통해 client가 authorized code=3이라는 것을 알 수 있게 됩니다.

5. client가 authorization code를 획득하면 resource server로 정보를 전송하는데 형식은 다음과 같습니다.

• [https://서버주소/?grant_type=authorization_code&code=3&redirect_uri=https://리다이렉트주소&client_id=1&client_secret=2]

6. authorization code와 client secret 두 개를 결합해서 resource server에 전송합니다. client로 부터 받은 authorization code를 확인한 후 server에서 가지고 있는 코드 정보를 확인하고, 모든 정보가 일치하면 authorization code를 삭제하고 access token을 client에 발급해줍니다.

• client ID는 user ID가 아니라 어플리케이션의 식별자 ID이다.

• 등록 과정은 developer에서 client를 등록하는 과정을 말한다(ID와 secret을 server에 저장함).

• 리다이렉트 주소는 client(어플리케이션) 주소이다. call back.

• header에 location을 추가하면 설정한 주소로 페이지 이동이 가능하다.

[전체적인 Authorization code grant 흐름]

<조사하면서 계속 헷갈렸던 부분>

• Auth와 OAuth의 차이는? 토큰을 사용하느냐 사용하지 않느냐의 차이이다. 보안을 강화하기 위해 나온 방식이 OAuth이다. Auth는 Authentication(인증), OAuth는 Authorization이다(권한).

• OAuth 서버라는 것이 무엇을 의미하는 것인가? 말 그대로 oauth2.0을 구현하는 것을 말하는 것 같다.

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를 통해 자체 정보를 업데이트하려고 할 때 사용될 수 있다.

1. firebase 가 OAuth server를 제공하는지

2. firebase에서 이메일+비밀번호로 로그인하는 과정 다시 한 번 공부하고 정리하기

firebase - 이메일로 로그인하기

• 가입과 로그인이 편리하다.

• 다른 SNS계정이 없어도 된다.

• 비밀번호를 입력하거나 기억할 필요가 없다.

1. user에게 이메일 제공 요청하는 인터페이스를 제공한다.

2. sendSignInLinkToEmail을 호출하여 firebase가 user의 이메일에 인증 링크를 전송하게 한다.

3. 이메일 링크를 만드는 방법에 대한 지침을 제시하는 actionCodeSettings객체 생성

1. url : redirect 할 주소, 이를 통해 이메일 확인, 비밀번호 재설정, 이메일 변경, 이메일 취소 등의 기능을 설정할 수 있다.

2. 사용앱(android 또는 ios)설정

3. handleCodeInApp : true

4. dynamicLinkDomain

4. user에게 이메일 인증을 요청한다.

5. 이메일 로그인을 user가 완료할 경우 사용자의 이메일을 저장한다.

6. 위 과정을 통해 이메일 링크로 로그인을 완료한다.

• 보안 문제

1. 로그인하려면 로그인 이메일 주소가 처음에 로그인 링크를 보낸 주소와 일치해야 한다.

Admin Auth API

Firebase Admin SDK를 사용하면 자체 서버를 firebase 인증과 통합할 수 있다. 또한 Admin SDK로 사용자를 관리하거나 인증 토큰을 관리할 수 있다. Firebase사용자를 관리할 때마다 Firebase콘솔에 접속하기는 번거롭기 때문에 사용자에게 API를 제공한다. 또한 firebase에서 제공하지 않는 회사의 ID(ex 카카오, 네이버)와 연결하고 싶을 때 사용한다. firebase 인증의 기본적인 용도는 앱의 사용자를 식별하여 firebase 실시간 DB, cloud storage 등의 다른 firebase 서비스에 대한 액세스를 제한하는 것이다. 하지만 인증 서비스(Admin Auth API)를 통해 firebase가 아닌 내 서버에서 이러한 사용자 식별이 가능하다.

결론 : firebase에서의 부족한 점을 보완하기 위한 API이다.

웹 표준이란

월드 와이드 웹의 측면을 서술하고 정의하는 공식 표준이나 다른 기술 규격을 가리키는 일반적인 용어이다. 예를 들어 W3C가 있다.

JWT(다시 정리)

사용자 정보를 json객체에 담아 이를 암호화하고 해싱작업을 거쳐 문자열 토큰을 생성하는 인증 방식이다. 이 토큰을 HTTP header에 추가하여 요청을 보냄으로써 사용자 인증을 얻게 된다. 권한 claim이라고 하는 정보에 디지털 서명을 한 후 비밀 서명키로 검증하는 도구이다. JWT는 OAuth와 같이 token기반의 인증방식이다.

형태 : 세 가지의 문자열(헤더, 페이로드, 시그니처)로 이루어져 있다.

인증방식으로 session, JWT, baseAuth(login, password)

JWT와 OAuth의 차이

OAuth와 JWT 둘 다 token 방식을 사용하지만 OAuth의 토큰은 아무 의미 없는 문자열 형태이기 때문에 서버에서 토큰과 연관된 정보를 탐색하고 기능을 수행한다. 하지만 JWT는 토큰 자체가 의미를 갖는 claim 기반의 토큰 방식이다. 이 토큰을 HTTP header에 추가하여 사용자 인증 요청을 보낸다. 그러면 서버에서는 이 토큰을 확인하고 디코딩하여 사용자를 인증한다.

1. OAuth와 Auth의 차이

2. firebase의 auth과정

3. firebase는 oauth server가 가능한가

OAuth와 Auth의 차이?

• 간단하게 말하자면 액세스 토큰을 사용하느냐, 사용하지 않느냐의 차이

• Authentication(auth) : ‘누구인지’에 대한 정보를 다룬다. 최종 사용자 주체를 결정하는 프로세스이다. 주체를 결정하는 데에는 ID, 비밀번호, 홍채 인식 등 여러가지 방법이 있다.

• Authorization(OAuth) : ‘누구에게 권한을 부여했는지’에 대한 정보를 다룬다. 요청한 권한과 권한을 요청한 client 응용 프로그램을 연결하는 프로세스이다. 액세스 토큰은 연결을 나타낸다.

openID란

하나의 URI로 인터넷 상에서 식별이 가능하게 해 준다. 하나의 아이디로 여러 인터넷 사이트를 이용할 수 있는 인증 서비스를 말한다. openID를 만들면 openID지원하는 다른 웹 사이트에서 쉽고 편리하게 로그인 할 수 있다. openID를 사용하면 새비밀번호를 만들 필요가 없다. ID를 공유함으로써 신원을 확인할 수 있다.

JWT란

JSON Web Token의 약자로 토큰 기반 인증하는 웹표준이다.  stateless하다.

① stateful 서버 : 클라이언트로부터 요청을 서버가 받을 때, client에서 상태유지를 해야한다.

② stateless 서버 : 상태유지가 되지 않으며, 상태정보를 저장하지 않으면 클라이언트로 들어오는 요청만으로 작업 처리한다. 상태가 없는 경우 client와 server의 연결고리가 없기 때문에 서버의 확장성이 높아진다.

• 새로운 회원이 가입할 때 ①일경우 server의 서버나 세션에 새로 저장을 해야 하기 때문에 용량이 점점 늘어난다. RAM이 과부하가 될 수 있다.

JWT는 헤더(header).내용(payload).서명(signature) .을 기준으로 세 가지 문자열로 이루어져 있다.

1. 헤더 header

1. typ : 토큰의 두 가지 타입을 지정한다. 여기서는 JWT이다.

2. alg : 해싱 알고리즘을 지정한다.

3. 예시 : const header = { “alg” : “HS256”, “typ” : “JWT” } 형식으로 인코딩한다.

2. 정보 payload

1. 토큰에 담을 정보를 나타낸다. 정보의 ‘한 조각’을 claim이라고 한다.

1. 등록된(registered) 클래임 : iss,sub,aud,exp,nbf,iat 등

2. 공개(public) 클래임 : 충격이 방지된 이름을 가져야 한다. 중복 될 수 없다. uri형식으로 이름을 짓는다.

3. 비공개(private) 클래임 : 양 측(client, server)간의 협의하에 사용되는 것을 나타낸다. 이름간 충돌이 되어도 상관없다.

3. 서명 signature

1. 헤더의 인코딩 값과 정보의 인코딩 값을 합친 후 주어진 비밀 키로 해시하여 생성한다.

* 토큰은 삭제가 불가능하기 때문에 만료시간을 넣어주는 것이 좋다.

1. OAuth 공부 다시 제대로

2. OKTA홈페이지

3. OAuth flow이해하기 + flow만들기

4. 질문

1. Auth와 OAuth의 차이는?

2. firebase OAuth 서버가 가능한가?

3. firebase가 제공하는 인증기능이 무엇인가? OAuth와 다른 것인가

[OAuth 2.0]

클라이언트가 서버에 등록하기 위한 필수 요소 세 가지는 client ID, client secret, authorized redirect URIs이다. 다시 말해, 클라이언트를 서버에 등록을 하게 되면 client ID와 client secret을 얻게 된다. client ID는 우리가 만든 어플리케이션의 식별자 ID이며, secret은 그에 대한 비밀번호이고, redirectg URIs는 리소스 서버가 권한을 부여하는 과정에서 authorized code라는 것을 전달하는데, 이 코드를 이 URI로 전달한다.

1. 먼저 owner가 client에 접근하게 되면, client는 server의 기능이 필요하기 때문에 server에 먼저 로그인해야 된다는 화면을 띄워준다. 이때 ‘구글로 로그인’ 버튼의 주소는 [http://서버 주소&scope=b,c&client_ID=1&redirect_uri=리다이렉트 주소]의 형식으로 되어있다.

2. owner가 이 버튼을 누르면 server로 접속하게 된다. server에 로그인을 성공하게 되면 주소의 client id 값이 server에 등록된 client id값과 동일한지 확인하고, redirect URI도 확인한 후 모두 같으면 client에서 요청한 scope를 제공하는데 동의할 것인지의 여부를 owner에게 묻는다.

3. owner가 허용하게되면 허용했다는 메시지를 server에게 전송하고, server가 전송을 받으면 client에서 요청한 기능(scope)를 server에 저장한다.

4. scope를 server에 저장하고, 정보가 저장된 authorized code를 발급한다. 이 authorized code를 owner에게 전송하는데, 헤더값으로 [location:https://redirect_uri?authorized_code=3]을 준다. 이를 통해 owner를 redirect 시킬 수 있다. 이를 통해 client가 authorized code=3이라는 것을 알 수 있게 된다.

5. client가 authorization code를 획득하면 resource server로 정보를 전송하는데 형식은 다음과 같다.

• [https://서버주소/?grant_type=authorization_code&code=3&redirect_uri=https://리다이렉트주소&client_id=1&client_secret=2]

6. authorization code와 client secret 두 개를 결합해서 resource server에 전송한다. client로 부터 받은 authorization code를 확인한 후 server에서 가지고 있는 코드 정보를 확인하고, 모든 정보가 일치하면 authorization code를 삭제하고 access token을 client에 발급해준다.

• client ID는 user ID가 아니라 어플리케이션의 식별자 ID이다.

• 등록 과정은 developer에서 client를 등록하는 과정을 말한다(ID와 secret을 server에 저장함).

• 리다이렉트 주소는 client(어플리케이션) 주소이다. call back.

• header에 location을 추가하면 설정한 주소로 페이지 이동이 가능하다.

[전체적인 OAuth 흐름]

• Auth와 OAuth의 차이는? 토큰을 사용하느냐 사용하지 않느냐의 차이이다. 보안을 강화하기 위해 나온 방식이 OAuth이다. Auth는 Authentication(인증), OAuth는 Authorization이다(권한).

• OAuth 서버라는 것이 무엇을 의미하는 것인가? 말 그대로 oauth2.0을 구현하는 것을 말하는 것 같다.

• firebase OAuth 서버가 가능한가?

• firebase가 제공하는 인증기능이 무엇인가? OAuth와 다른 것인가