IT's 잡탕찌개 블로그

OIDC(OpenID Connect)에 대해서 알아보자.

OIDC란 OAuth2.0 기반으로 유저를 인증하는 프로토콜이다.

OAuth2.0과 다소 차이점이라 함은 OAuth가 Athorization을 포함한다면 OIDC는 Authentication에 집중한다는 점이다.

OIDC를 사용하는 방법은 매우 간단하다.

OAuth 를 통해 Access_token을 받을 때 id_token이라는 것도 같이 전달 받는데 이 id_token을 활용하면 된다.

구글을 예로 들면 OAuth2.0에서 token을 요청할 때 response_type, client_id 등을 넘기게 되는데 이 때 scope에 

필요한 정보에 대해서 명시하게 되어 있다.(openid profile email 등등)

이 scope에 명시한 정보들은 추후 id_token을 받을 때 안에 포함되어 전달된다.

따라서 OAuth을 통한 API호출이 아닌 단순 유저 인증 및 기본정보 등을 알기위해서라면 OIDC를 사용하는것이 더 좋다.

구글에서 OIDC는 JWT을 사용한 id_token을 전달해주므로 해당 token의 위변조 확인 후 관련 정보를 활용하면 된다.

공식 레퍼런스 : https://developers.google.com/identity/protocols/oauth2/openid-connect

웹 싸이트에서 유저의 인증을 확인하는 방식에는 여러 방식이 존재한다.

각 방식에 대해서 간단하게 알아보자.

1. 단순하게 Http Header에 특정 정보를 전달하는 방식.

- 해당 방식은 Client와 Server가 통신할 때마다 Header 에 Id, pw 등의 정보를 포함 시킨 후 

통신하는 방식이다. 매 통신마다 해당 정보를 검증하며 위조여부 등을 판단한다.

-> 단점 :

. 해커가 해당 패킷을 탈취 시 중요 정보가 유출된다.

. 매번 인증정보를 확인해야 하며 이는 비효율적이다.

-> 장점 : 

. 구현이 쉽다.

2. 서버가 유저 인증 시 특정 세션정보를 활용하는 방법.

 - 유저의 로그인 절차 중 해당 정보가 인증된다면 이 유저에 대한 세션ID를 부여한다.

그 후 세션 ID를 Header에 포함시켜 보내면, client는 해당 session id 를 쿠키에 저장한 후 

서버와 통신할 때 인증정보가 필요한 경우 header에 포함시킨다.

-> 단점 : 

. 이 역시 해커가 탈취 시 중요 정보의 유출 위험이 존재한다.

 -> 세션 별 life time 을 설정해서 유효시간을 지정함으로서 탈취된 경우 무효화 될 수 있게 한다.

 -> HTTPS를 적용하여 탈취 후 에도 header를 파악하기 어렵게 한다.

. 세션을 저장할 추가적인 비용(DB, memory 등)가 발생한다.

-> 장점 : 

. 패킷 탈취 시 해당 session ID로만 구성되어 있으므로 유의미한 정보는 유출되지 않는다.

3. Token 기반 인증방식을 적용한다.(보통은 JSON Web token 사용)

 - token 정보를 header에 포함시켜 전달하는 방식이다. jwt의 경우 지정된 암호화 방식으로 tokenize를 진행할 수 있고 이에 대한 SECRET KEY 로 복호화 후 위변조 여부를 판단할 수 있다.

jwt의 경우 Header, payload, verify signature 로 구성되며 header, payload는 누구나 복호화 할 수 있고 verify signature의 경우 SECRET KEY를 알지못하면 복호화 하지 못한다. 따라서 payload에는 중요정보를 포함하면 안된다.

-> 단점 : 

 . 이 방식 역시 해커가 탈취가능하다.

 -> 이 역시, access token에 expire time을 적용하면 피해를 다소 방지할 수 있다.

 . payload는 복호화가 가능하기 때문에 넣을 수 있는 data는 한정적이다.

 . 서버에서 복호화하는 비용이 발생한다.

-> 장점 : 

 . session 인증 방식과 크게본다면 동일하지만 볃도의 비용이 발생하진 않는다.(DB 불필요)

 . 탈취 당한다고 해도 token 위조가 무의미해진다.

OAuth2는 기존의 OAuth가 모바일 친화적이지 않다는 단점을 보완하여 개발된 인증 시스템이다.

기존 OAuth 보다 사용하기 간편하며, 이미 구글, facebook등 여러 서비스에서  OAuth2를 도입한 상태이다.

기존 OAuth와의 차이점은 아래와 같다.

 . HTTPS를 통한 인증으로 보안 강화

 . 모바일 친화적

 . AccessToken에 만료기간 적용.

관련 용어는 아래와 같다.

 . Client : 구글 로그인 등을 사용하는 특정 서비스.

 . Resource Owner : 특정 서비스를 사용하는 사용자

 . Authorization Server : 해당 사용자의 인증을 담당하는 서버

 . Resource Server : 해당 사용자가 사용할 수 있는 API등의 자원을 제공하는 서버