정리_

D+36

와 벌써 현장실습 끝나가...

어쩌면 좋으늬...ㅎ... authorization server 완성 못하고 끝낼듯ㅠㅠ

client ID, client secret, redirect uri는 default 값으로 내가 지정한다.

authorization code, access token은 인코딩

authorization code요청

https://resource.com?client_id=abc&redirect_uri=http://client.com

access token 요청

https://resource.com?client_id=abc&client_secret=1234&grant_type=authorization_code&code=cba&state=good

access token 형태(JSON)

{

“access_token”:”aaaAbcD+1234”,

“refresh_token”:”Abced1gf5”,

“token_type”:”bearer”,

“expires_in”:”3600”

}

base64란?

8비트 이진데이터를 ACSII문자로 변화하거나 그 반대로 변환하는 인코딩 방법을 말한다. 64가 2의 제곱수이며, 2의 제곱수들에 기반한 진법들 중에서 화면에 표시되는 ASCII코드를 써서 표현할 수 있는 가장 큰 진법이다.

만드는 방법

1. 문자에 해당하는 ASCII코드로 바꾸어준다.

2. 그 ASCII코드를 8bit 이진수로 바꾸어준다.

3. 2에서 8bit로 바꾸어준 숫자를 6bit씩 끊어준다.

4. 6bit씩 끊은 수를 다시 10진수로 변환한다.

5. 마지막으로 10진수로 변환한 숫자를 Base64의 색인표에 따라 숫자에 해당하는 알파벳으로 변환해준다.

6. 만약 남은 비트가 3byte미만이라면 버퍼의 남은 부분을 0으로 채워준다.

7. 문자의 끝에는 끝을 알리는 ‘=’을 추가해준다.

<script>

opener : 팝업창에서 부모창으로 이동할 때 사용한다.

아래 코드 팝업 창을 나타낸 코드인데, ‘승인’버튼을 누르면 부모 창이 “http://localhost:3000/public/signup_O.html”로 이동하는 코드이다.

3000번 - 로그인

4000번 - ★☆로 로그인 화면, 동의 팝업창, 동의하면 코드생성&보내기

5000번 - 3000번이 코드 받은 뒤에 5000번으로 접근, 그 전까지는 4000번이 5000번으로 접근

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

쿼리 문자열 받아와서 사용하는 법 & 구현하기

(코드에 문제 있다고 표시한 부분부터 확인하기)

code어떻게 받아올 것인지 고민

client id, secret, redirect uri어디에 저장할 것인지 고민(client server와 oauth server 각각)

내일 세가지 완성하기

D+33

oauth2-server모듈 공부하기

[단어정리]

API란?

사전적인 의미로는 Application Programming Interface의 약자로 응용 프로그램에서 사용할 수 있도록 운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻한다고 한다. 프로그램과 또 다른 프로그램을 연결해주는 역할을 한다고 볼 수 있다. 즉 어플리케이션의 프로그래밍을 위한 인터페이스라고 할 수 있다. 프로그램간 커뮤니케이션을 담당한다.

restAPI란?

• REST(REpresentational State Transfer) : 대표적인 상태 전달.

 웹에 존재하는 모든 자원에 고유한 URI를 부여해 활용하는 것으로 자원을 정의하고 자원에 대한 주소를 지정하는 방법론을 의미한다. 따라서 Restful API는 REST특징을 지키면서 API를 제공하는 것을 말한다.

 어플리케이션의 복잡도가 증가하면서 어플리케이션을 어떻게 분리하고 통합하느냐가 주요 이슈가 되었고, 그래서 REST가 떠오르고 있다.

• REST의 구성

1. 자원(resource) : URI

2. 행위(verb) : HTTP Method

3. 표현(representations)

ex) /users GET

         /users/{id} GET

    /users PUT

• REST의 특징

1. uniform(유니폼 인터페이스) : HTTP표준에만 따른다면, 특정언어나 기술에 종속되지 않고 모든 플랫폼에 사용이 가능하며, URI로 지정한 리소스에 대한 조작이 가능한 아키텍처 스타일을 의미한다.

2. stateless(무상태성) : HTTP는 Stateless Protocol이므로 REST역시 무상태성을 갖는다. 즉, HttpSession과 같은 컨텍스트 저장소에 상태정보를 따로 저장하고 관리하지 않고, API 서버는 들어오는 요청만을 단순 처리하면 된다. 세션과 같은 컨텍스트 정보를 신경쓸 필요가 없어 구현이 단순해진다.

3. cacheable(캐시가능) : HTTP기존의 웹표준을 그대로 사용하기 때문에 웹에서 사용하는 기존의 인프라를 그대로 활용이 가능하다.

4. self-descriptiveness(자체표현구조) : method+url로 이루어져있어 어떤 메소드에 무엇을 하는지 알 수 있으며, 메시지 포맷 역시 json을 이용해 직관적으로 이해가 가능한 구조이다.

5. client-server구조 : 클라이언트와 서버의 역할이 구분되어, 서로 간의 의존성이 줄어든다.

[OAuth2-server 모듈]

<사용 예시>

<특징>

1. scope와 함께 인증 코드, 클라이언트 자격증명, 토큰 및 비밀번호 부여 새로고침 및 확장 승인을 지원한다.

2. RFC 6749 및 RFC 6750을 준수한다.

3. 모든 형태의 저장소를 지원한다. ex) MySQL, MongoDB, Redis 등

<API>

1. OAuth2Server

• new OAuth2Server(options)

option의 타입은 object이다. OAuth2Server의 authenticate(), authorize(), token()에 대한 유효한 옵션은 생성자에도 전달될 수 있다. 제공된 옵션은 다른 메소드의 기본값으로 사용된다.

• authenticate(request, response, [options], [callback])

• authorize(request, response, [options], [callback])

authorize는 토큰이 필요하다.

• token(request, response, [options], [callback])

승인된 토큰 요청에 대한 새토큰을 검색한다.

2. Request

3. Response

4. Errors

[관련 모듈 설명]

oauth2orize 모듈은 OAuth2.0의 핵심 flow를 node.js로 구현해 놓은 것이다. 요청된 인증타입에 따라서 개발자가 등록해 놓은 callback function을 호출하고 해당 function이 리턴한 결과를 적절히 http resource로 만들어 client에 응답하는 모듈이다.

passport-oauth2-public-client 모듈은 authorization server가 client id만으로 client검증을 하는 경우에 사용한다. Authorization Code grant type에서 client가 access token을 요청하기 전에 code를 얻기 위해 요청하는 경우가 해당된다. 이 모듈은 http body의 client_id값을 개발자가 등록한 callback function으로 넘겨준다. client id가 유효한지 여부는 개발자가 따로 검사해야 한다.

passport-http 모듈은 authorization server가 client id와 secret을 검증할 때 사용한다. 즉, authorization code grant type이나 resource owner password grant type이 access token을 요청한 경우를 말한다.

<API 설정>

1. /oauth2/authorize

2. /oauth2/authorize/decision

3. /oauth2/token

scope를 설정할 때에는 scope를 정의하고 http body의 scope필드를 활용하면 된다.

<database 설정>

authorization server가 데이터를 가지고 있어야 한다.

1. 등록된 client에 대한 정보

1. client name

2. client id

3. client secret

4. refresh token 여부

5. callback uri

2. 등록된 사용자들의 id와 password

3. access token을 얻기 위해 발행된 code정보

4. 발행된 access token정보

D+32

어떤 페이지 구현할 것인지

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

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

mySQL/mongoDB사용

mysql설치하기

[node.js+mysql] 회원가입/로그인 구현하기

mysql을 사용하기 위해 먼저 app.js파일에 연결 설정을 해주어야 한다.

관계형 데이터베이스에 연결할 때에는 보통 커넥션 풀(connection pool)을 사용한다. 이는 데이터베이스 연결 객체가 너무 많이 만들어지는 것을 막고 한 번 만든 연결을 다시 사용할 수 있게 한다. 커넥션 풀은 createPool 메소드에 객체를 추가하여 만든다. 객체의 종류에는 connectionLimit, host, port, user, password, database, debug가 있다.

사용자를 등록하는 함수 즉, 회원가입 하는 함수이다. 데이터를 객체로 만드는 부분은 회원가입 과정에서 이름, 아이디, 패스워드 등을 입력할 때 한 묶음으로 정보를 저장하기 위한 과정이다. 객체 안의 정보가 하나라도 틀리면 그는 일치하는 정보가 아닌 것이다. SQL문으로 표현하면 다음과 같다.

사용자를 인증하는 함수 즉, 로그인 하는 함수이다. 클라이언트로부터 전달받는 파라미터는 아이디와 비밀번호이다. authUser함수는 두 개의 파라미터와 함께 콜백 함수를 전달 받는다. 그 안에서 getConnection 메소드를 통해 커넥션 풀에서 연결 객체를 가져온다. 그 다음에는 연결 객체의 쿼리 메소드로 SQL문을 실행하는데 데이터를 조회해야 하기 때문에 select문을 사용한다. 쿼리 메소드로 전달하는 첫 번째 파라미터는 SQL문이고 두 번째 파라미터는 배열객체이다. 쿼리문은 ?? 또는 ? 기호를 통해 나타낸다.

OAuth와 JWT

JWT는 토큰 유형이고 OAuth는 토큰을 발급하고 인증하는 방식이다. 또한 bearer기반의 토큰방식이다. access token은 주로 세션에 담아서 관리한다. refresh token은 중요하기 때문에 주로 데이터베이스에 저장하고 관리한다.

oauth2-server 모듈 사용

app.oauth = oauthserver({

model : require(‘./oauth/model’), //oauth2의 각종 인증 함수를 구현해 놓은 곳

grants : [‘password’],

debug : true

});

[oauth2-server 모듈 공부하기]

https://www.npmjs.com/package/node-oauth2-server - 참고하기

https://oauth2-server.readthedocs.io/en/latest/docs/getting-started.html - 여기도 참고하기

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설치하기

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에 추가하여 사용자 인증 요청을 보낸다. 그러면 서버에서는 이 토큰을 확인하고 디코딩하여 사용자를 인증한다.