이 글은 이전 글에서 다룬 OAuth 프로토콜의 다음 편입니다.
- OAuth 프로토콜: https://malwareanalysis.tistory.com/889
OAuth프로토콜
이 글은 OAuth프로토콜이 무엇인지 설명하게 간단한 예제를 설명합니다.- 목차OAuth 프로토콜이란?OAuth 프로토콜 약점토큰을 받는 과정용어핸즈온 1. Google Playground핸즈온 2. 내가 만든 애플리케이션
malwareanalysis.tistory.com
OAuth 프로토콜의 역할
OAuth 프로토콜은 권한을 위임하고 제어하는 승인 프로토콜입니다. 즉, 사용자가 누구인지 확인하는 인증은 OAuth 프로토콜의 역할이 아닙니다.
OIDC 프로토콜이란
OIDC(OpenID Connect)는 OAuth 프로토콜을 기반으로 인증 기능을 추가한 프로토콜입니다. OIDC는 토큰 생성 과정에서 액세스 토큰과 함께 ID 토큰을 생성합니다. 이후 client가 리소스에 접근할 때 두 토큰을 사용해야 합니다.
이전에 작성한 OAuth 핸즈온 문서는 실제로 OAuth가 아니라 OIDC 프로토콜을 사용합니다. 그래서 authorization server에서 액세스 토큰과 ID 토큰을 모두 발급받았습니다.
authorization server는 OIDC인지 OAuth인지 어떻게 구별할까?
authorization server는 OIDC 프로토콜이면 ID 토큰과 액세스 토큰을 생성합니다. 반면 OAuth 프로토콜이라면 액세스 토큰만 발급합니다.
그렇다면 authorization server는 OIDC인지 OAuth인지 어떻게 구별할까요? OAuth 프로토콜 과정에서 scope에 openid를 포함하면 됩니다. authorization server는 scope에 openid가 있으면 OIDC 프로토콜로 인식합니다.
아래는 OAuth 핸즈온에 사용한 코드 예입니다. 아래 코드를 실행하면 scope에 openid가 있기 때문에 authorization server는 OIDC 프로토콜로 인식합니다.
- OAuth 핸즈온 코드: https://github.com/choisungwook/portfolio/blob/master/computer_science/oauth/app/main.py
OIDC 프로토콜은 인증을 어떻게 할까?
OIDC 프로토콜에서 인증 방법은 authorization server가 결정합니다. 즉, 인증 방식은 표준으로 고정되어 있지 않고 구현에 따라 달라질 수 있습니다.
OIDC 문서에서는 authorization server가 인증을 수행할 책임이 있다고 설명합니다. 인증 방법은 다양한 방식으로 구현할 수 있다고 명시되어 있습니다.
ID 토큰은 어떤 형식일까?
ID 토큰은 JWT 형식입니다.
OAuth 핸즈온을 실행하면 받은 id_token을 받을 수 있습니다. id_token은 JWT이고 jwt.io에서 디코딩 할 수 있습니다.
- OAuth 핸즈온 코드: https://github.com/choisungwook/portfolio/blob/master/computer_science/oauth/app/main.py
- jwt.io: https://www.jwt.io/
OIDC프로토콜에서 Client의 책임
Client는 ID 토큰(JWT)을 검증할 책임이 있습니다. 정말 올바른 authorization server가 발급한 ID 토큰인지 확인해야 하기 때문입니다. JWT를 분석하여 iss(발급자), aud(청중), exp(만료 시간) 등의 클레임이 맞는지 확인해야 합니다.
OIDC 사례 - github action
GitHub Actions가 AWS S3에 접근하려면?
AWS 리소스에 접근하려면 자격증명이 필요합니다. 자격증명에는 두 가지 유형이 있습니다:
- 장기 자격증명: access key처럼 만료 기간 없이 계속 사용 가능
- 임시 자격증명: 일정 시간 동안만 유효한 자격증명
따라서 GitHub Actions도 S3에 접근하려면 자격증명을 사용해야 합니다.
임시 자격증명을 사용해야 하는 이유
GitHub Actions에서 access key처럼 장기 자격증명을 사용하면 보안 위험이 커집니다. 장기 자격증명은 노출되면 누구나 사용할 수 있기 때문에 보안적으로 권장하지 않습니다. 그러므로 GitHub Actions에서는 임시 자격증명을 사용하는 것이 권장됩니다.
GitHub Actions는 OIDC를 무슨 목적으로 어떻게 사용할까?
AWS에서는 assume role을 실행하면 임시 자격증명을 받을 수 있습니다. 하지만 임시 자격증명을 요청한 주체가 정말 GitHub Actions인지 확인할 방법이 없습니다. 이때 AWS는 GitHub Actions인지 확인하고 인증하기 위해 OIDC를 사용합니다.
GitHub Actions는 assume role을 할 때 GitHub Authorization Server가 발급한 ID 토큰을 함께 전달합니다. 그리고 AWS는 받은 GitHub ID 토큰이 유효한지 검증합니다.
GitHub ID 토큰은 GitHub Authorization Server(또는 IDP)만 만들 수 있습니다. GitHub ID 토큰은 공개키 방식으로 만들어지므로 AWS는 JWKS 엔드포인트에서 공개키를 가져와 ID 토큰을 검증합니다.
위 과정을 간단히 정리하면 아래와 같습니다.
Github Actions workflow 예
Githb Action workflow에서는 permission.id-token이 write로 설정되야 합니다.
name: AWS OIDC Test
on:
workflow_dispatch:
push:
branches:
- main
permissions:
id-token: write
contents: read
jobs:
test-aws-oidc:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Configure AWS credentials using OIDC
uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
aws-region: ap-northeast-2
# - name: Verify AWS identity
# run: |
# echo "Verifying AWS identity..."
# aws sts get-caller-identity
- name: List S3 buckets
run: |
echo "Listing S3 buckets..."
aws s3 ls
AWS에서 IAM 설정하기
AWS 입장에서 GitHub Authorization Server(IDP)는 AWS 리소스가 아니므로 신뢰(Trust) 설정을 해야 합니다. 신뢰 설정은 IAM Identity Provider에서 할 수 있습니다.
그 외에 GitHub Actions가 사용하는 IAM role에 Trust Relationship 설정도 필요합니다. Trust Relationship 설정에는 assume role을 할 수 있는 GitHub 레포지토리를 한정시킬 수 있습니다.
참고자료
'전공영역 공부 기록' 카테고리의 다른 글
| OAuth프로토콜 (0) | 2026.01.01 |
|---|---|
| EKS ALB controller에서 gateway API 사용하는 방법 (0) | 2025.12.30 |
| Kubernetes Gateway API 간단히 알아보기 (2) | 2025.12.30 |
| eBPF와 함께하는 Cilium 핸즈온: Pod부터 Service 통신까지 (1) | 2025.12.27 |
| 공식문서로 이해하는 eBPF 입문 (0) | 2025.12.23 |