정리_

오늘은 전에 정리해 두었던  OAuth2.0의 네가지 인증방식의 플로우를 정리해보려고 합니다.

쿼리 문자열에 클라이언트 아이디, 코드, 리다이렉트 URI등을 포함시켜 get 또는 post 방식으로 넘겨주는 방식으로 서버 사이에서 서로 정보(?)를 주고 받습니다.

아래는 각 인증방식의 플로우와 각 번호의 추가적인 설명을 적어보았습니다ㅇ...

먼저 Resource Owner Credential Grant Type입니다. Password Grant라고도 합니당

이 타입은 자사 앱(client)에 직접 로그인하는 방식을 말합니다. 그렇기 때문에 code를 발급받을 필요없이 client로 바로 로그인이 가능합니다.

2. 클라이언트는 포스트 방식으로 매개변수를 전달합니다

- grant_type(여기서는 password)

- client_id

- client_secret

- scope

- username, password

4, 5. authorization server는 아래 내용을 포함하는 JSON파일로 응답합니다.

- token_type(bearer)

- expires_in

- access_token

- refresh_token

다음은 Authorization Code Grant Type입니다

1. 사용자가 client에 접속합니다.

2. 리다이렉트 할 때 문자열 매개변수에 다음을 포함합니다.

- response_type

- client_id

- redirect_uri

- scope

- state with a CSRF token (선택사항)

3. 사용자가 로그인 정보를 전달합니다(로그인 시도).

4. 로그인에 성공하면 2번에서 쿼리 스트링에 포함시켜 넘어온 클라이언트 아이디, 리다이렉트 uri등을 확인하여 일치하는지 확인합니다.

5, 6. owner가 승인하면 client로 리다이렉트할 때 쿼리 매개변수에 다음을 포함합니다.

- code(authorization code를 말합니다)

- state(client로부터 받은 정보 일치 여부 상태를 말합니다)

7. code를 통해 client가 authorization server에 직접 접근할 수 있게 됩니다. client가 POST요청을 보낼 때 쿼리 매개변수에 다음을 포함합니다.

- grant_type(여기서는 authorization_code를 말합니다)

- client_id

- client_secret

- redirect_uri

- code(authorization code)

8. code와 7번에서 받은 정보들을 확인하여 전부 일치하면 access token을 발급합니다. authorization server는 아래 내용을 포함하는 JSON파일로 응답합니다.

- token_type

- expires_in

- access_token

- refresh_token

9. client는 token을 통해 resource server에 직접 접근할 수 있게 됩니다.

* 이때 보통 access token의 유효기간(expires_in)은 한시간 정도입니다. access token의 유효기간이 지나면 refresh token을 통해 access token을 다시 발급받고 resource server에 접속할 수 있게 됩니다.

세번째로는 Implicit Grant Type입니당

이 방식은 authorization code grant type과 비슷하지만 code를 발급받지 않는다는 점과 refresh token이 없다는 점이 다릅니다.

2. 리다이렉트 할 때 쿼리 문자열의 매개변수를 사용해서 다음을 포함합니다.

- response_type

- client_id

- redirect_uri

- scope

- state with a CSRF token (선택사항)

5, 6. owner가 승인하면 client로 리다이렉트 할 때 쿼리 매개변수에 다음을 포함합니다.

- token_type

- expires_in

- access_token

- state(client로부터 받은 정보가 일치하는지 여부 상태를 말합니다)

* Implicit grant type은 refresh token이 없습니다. 

마지막으로 Owner가 없는 Client Credential Grant Type입니당

이 방식은 owner가 존재하지 않으며, client가 직접 authorization server에 접근할 수 있습니다.

1. client가 POST방식으로 쿼리 매개변수를 전달합니다.

- grant_type(여기서는 client_credentials입니다)

- client_id

- client_secret

- scope

4, 5. authorization server는 아래 내용을 포함하는 JSON파일로 응답합니다.

- token_type(bearer)

- expires_in

- access_token 

확실히 authorization code grant type만을 집중적으로 공부해서 그런지 2번만 그나마 자세히 써지는 것 같네요,,,

좀 더 공부해야 할 것 같습니다. 제가 혼자 공부하면서 만들어 본 flow라 틀린 내용이 있을 수도 있습니다... ㅠ3ㅜ.....

클라이언트가 서버에 등록하기 위한 필수 요소 세 가지는 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 공부 다시 제대로

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와 다른 것인가