정보보안_7_Authorization

이번장에선 Access control의 두번째 파트, 인가에 대해 다루겠다.

 

Authorization 인가란?

사용자, 시스템이 어떤 동작을 할 수 있게 권한을 부여하는 것. 특정 리소스에 접근권한을 부여하는 것을 의미한다.

 

특히 요즘은 카카오, 네이버등 소셜 계정으로 로그인을 하는 경우가 많다. 이때 카카오, 네이버는 클라이언트 App에게 사용자의 정보에 관한 접근 권한을 부여해야한다.

 

따라서 이를 위한 프로토콜이 필요한데, 대표적인 예가 OAuth 2.0이다.

 

OAuth 2.0

 

 

인증/인가와 관련된 framework로 외부에서 다른 서비스에 제한된 접근을 가능하게 한다.

RFC 6749에 명세를 따라, access tokens을 어떻게 발행할지에 관한 프로토콜이다.

 

이를 통해 제3자가 서버의 특정 리소스에 접근할 수 있는 접근 권한을 부여하는 인가 토큰을 발행하는

 

기본적인 단계는 다음과 같다. 

상황은 user가 무신사어플에 카카오계정으로 로그인을 하려고한다.

 

1. 무신사 어플은 사용자에게 카카오 계정의 유무를 물어본다.

2. 사용자가 있다고 관련 정보를 넘기며 가지고 있다고 응답한다.

3. 무신사는 카카오서버에게 사용자의 정보를 요청한다.

4. 카카오서버는 사용자에게 무신사에서 네 정보에 접근하려고하는데 허가여부를 묻는다.

5. 사용자는 카카오서버에 허가응답을 한다.

6. 카카오 서버는 응답을 들은 후 무신사에 사용자 정보를 준다. (정확하게는 사용자 정보에 접근이 가능한 Access Token을 발행한다.)

 

조금 더 세부적으로 이 과정을 설명하면 그림과 같은데 주목해야할 점은 6번의 과정에서 바로 Access Token을 발행하는 것이 아니다.

 

Authorization Code Flow

 

Authorization Code Flow

5번까지의 과정은 위와 동일하다. 그러나, 5번에서 허가응답을 받고 바로 Access Token을 내주는 것이 아닌, Access Token을 받을 수 있는 일시적인 authorization code를 Client Application(무신사)에 발행한다. 

이후 무신사는 해당 코드를 가지고 카카오 서버의 Token Endpoint에 접근하고 해당 포인트에서 Access Token을 발행 받을 수 있다.

 

왜 굳이 인가 코드를 발행하고 토큰을 발행하는 과정을 분리했을까?

사용자를 인가하는 과정과 토큰을 발행하는 과정을 분리시켜 보안성을 높이기 위해서! (하나의 역할만 하게 코드를 짠거지)

 

 

이 과정을 크게 4단계로 구분하면 다음과 같다.

 

1. 인가 요청을 Authorization Endpoint에 보낸다.

2. short-lived authorization code를 발행받는다.

3. authorization code을 통해 Token Endpoint에 Token 생성 요청을 보낸다.

4. Access Token을 받는다.

 

Client Credentials Flow

앞서 설명한 Authorization Code Flow는 일반적인 과정이었고 특수상황에서 비밀값을 안전하게 저장하는 Client에 대해 사용자 정보가 아닌 일반적인 Resource를 요청하는 경우에 쓰이는 경우로

사용자 인증과정이 빠지고, Access Token을 바로 Token Endpoint에 요청하는 과정을 의미한다.

 

Refresh Token Flow

이미 토큰을 한번 발급받은 이후에 재발급 받으려하는 경우에 Refresh Token을 Token Endpoint에 보내 다시 Access Token을 발급받는다.

 

 

OIDC(OpenID connect)

앞서 설명한 OAuth2.0은 리소스에 접근할 수 있는 접근 권한을 허가하는 프로토콜이다. OIDC는 OAuth2.0의 확장판으로 인증과 관련된 개념이 추가된 일종의 API이다.

앞서 OAuth2.0은 Clientn App에 리소스에 접근권한을 허용해주는 인가 프로토콜이었다.

OIDC는 OAuth2.0과 같은 흐름을 거치고 추가적으로 여기에 사용자 인증된 사용자의 개념을 더하기 위해 ID token을 발행한다. Access Token만으론 이 토큰을 가지고 있는 사용자가 누구인지 알 수 없다. (인증이 안되어있다.)

 

OAuth2.0 : Access Token을 발행 -> 사용자 정보에 접근할 수 있음

OIDC : ID Token을 발행 -> 사용자 ID, 로그인 시간, 이름.. 등의 정보를 알 수 있음.

 

OIDC를 사용하기 위해선 다음을 따라야한다

- 우선, API에 response_Type을 지정해줘야한다. response_Type이란, 필수요청 파라미터로 이 타입에 맞춰서 Response를 해달라고 요청하는 것이다. 예로는 code, Token, ID Token으로 지정할 수 있다.

- ID Token을 달라고 하는 요청에는 반드시 openid를 scope에 포함시켜야한다. 이게 없으면 ID Token은 발행되지 않는다.

 

 

ID Token이란 대체 무엇이냐?

- 특정 사용자의 개인정보가 포함되어 있다 : 사용자를 인증할때 Client App에 정보를 입력하지 않고 인증할 수 있음.

JWT 토큰의 형태를 띔. { header + Payload + Signature } 로 구분됨.

 

여기서 Payload를 Decode하면 다음과 같은 정보 들이 포함되어있다.

 

Response_Type에 따른 분류

 

Response_Type = code

scope에 openid가 같이 존재한다면, OAuth2.0과 같은 과정이나 Access Token을 줄때 ID Token을 같이 제공한다.

 

Response_Type = code 이나 openid가 존재하지 않는다면, ID Token은 발행되지 않는다.

 

Response_Type = Token이면 openid가 존재하더라도 ID Token은 발행되지 않고 Access Token만 발행된다.

 

Response_Type = id_token 이면, Access 권한이 아닌 사용자의 계정정보만 필요로할때 사용된다.

 

 

https://www.youtube.com/watch?v=1AVRkX4hIys 

개발할때 참고하면 좋을 것 같다.

OS Authorization

자, 지금까지는 Web환경에서 인증과 인가에 대해 알아보았다. 그렇다면 OS에서 인가는 어떨까?

 

• ACLs : Access Control Lists
• Capabilities

 

Access Control Matrix

행렬의 형태로 표현한다. 

subjects (users) 행에 위치

objects (resources) 열에 위치

 

다만, 이렇게 행렬로 표현을 하게된다면 1000명의 user와 resource가 존재하면 , Entry의 크기가 커질 것이다. 이는 많은 NULL을 야기해 공간낭비를 발생시킨다.

 

따라서, 효율성을 위한 group과 role을 구분한다.

 

 

ACLs : Access Control lists

object 중심(열을 중심으로 group한다.)

따라서, 리소스별로 해당 리소스에 접근이 허가된 subject에 접근하는 방식으로 사용자보다 Resources의 수가 많을 때 유리하다.

가령, 사용자가 다른 사용자에게 권한을 넘기는 상황이면,, 해당 사용자가 포함된 모든 리소스를 찾아 수정해야하니 할일이 많다...

UNix based system인 linux, macOs등에서 사용된다. 

 

Unix security : acl 기반의 16bit에 권한을 저장한다.

4 : 파일 종류 특수권한 3 3 3

 

또한, 유닉스에선 내 권한을 넘겨주는 방법이 없기때문에 이를 구현하기위해 set user id (suid)로 소유권을 잠시 이전하는 방법을 선택한다.

CL : Capabilities

이와 반대되는 개념으로  Cl이 존재한다. 이는 사용자 중심이다. 

권한을 위임하는 것이 쉽다. 소유권이 누구한테 있는지 확인하기 어려워 상태를 변경하기가 어렵다..

(MT촌 폐허가된 모텔이야기)

 

최근에 Cap 방식을 사용한다! 

 

DB관련 Access Control

자체적 DB만의 메커니즘이 존재하는데 효율성을 추구하기에 복잡하다! 

 

 

Browser 관련 Access Control

보안 공격의 위험요소 web code -> local접근 

 

SOP 소스하고만 통신하는 방법!!