[Study] 인증(Authentication)과 인가(Authorization) 차이점 정리
안녕하세요, 성조입니다.
예전에 첫 소통을 진행하다가 '인증'과 '인가'를 깜빡하고 혼용했던 경험이 있습니다. 한 번 정리하면서 정의를 까먹지 않고, 커뮤니케이션에서 숙달된 사용을 진행하기 위해 이해하는 시간을 가져보면 좋을 것 같다 판단하여 포스팅으로 다뤄봤습니다. 🙂
결론
인증 - 사용자가 누구인지 확인하는 과정입니다.
ex) 로그인
인가 - 인증된 사용자가 앱에서 원하는 서비스에 접근할 수 있는 권한을 확인하고 부여하는 과정입니다.
ex) 일반 유저가 운영자 페이지에 접근할 수 없도록 인가 설정이 되어 있는 것을 말합니다.
인증
인증은 사용자가 누구인지 확인하는 과정으로, 웹에 로그인하거나, 앱 서비스에 로그인할 때 사용되는 방법입니다.
사용자명(이메일 또는 계정 아이디)과 비밀번호, 인증 토큰 등 다양한 방법으로 로그인할 수 있게 됩니다.
기본 인증의 종류
1. 기본 인증
- 가장 간단한 형태의 인증 방식으로, 사용자가 사용자명과 비밀번호를 함께 서버에 전송하여 인증하는 방식입니다.
웹이나 앱 서비스에서 이메일, 비밀번호를 입력하는 방식으로 보면 좋습니다.
- HTTP 헤더 값에 통신을 보내 기본 인증을 구현할 수 있으며, 사용자명(이메일)과 비밀번호가 전달됩니다.
장점: 비교적 간단한 구현
단점: 보안 취약성
(단순 비밀번호를 전달하면 노출될 가능성이 높습니다. HTTPS가 필수적이며, 전달할 때도 암복호화와 코드에 솔트를 첨부해서 진행하는 것이 좋습니다.)
2. 폼 기반 인증
- 사용자가 로그인 폼을 통해 사용자명과 비밀번호를 입력하고, 서버에서 이를 확인하는 방식입니다.
- 사용자 정보가 HTTP POST 요청을 통해 서버로 전달됩니다.
장점: 사용자 친화적인 UI 제공
단점: 세션 관리가 필요하고, CSRF(Cross-Site Request Forgery)와 같은 공격에 취약할 수 있습니다.
3. 토큰 기반 인증 (Token-Based Authentication)
- 사용자가 로그인 시 토큰을 발급받고, 이후 모든 요청에 이 토큰을 포함하여 인증하는 방식입니다.
- 액세스 토큰(접근 토큰) 리프레시 토큰(반환 토큰) 두 개를 발급하는 편입니다.
- 토큰은 JWT(JSON Web Token) 형식으로, 클라이언트는 이 토큰을 로컬 저장소(예: Local Storage, Cookie)에 저장하여 사용합니다.
장점: 서버에 상태를 저장하지 않기 때문에 확장성이 좋음, CORS 지원
단점: 토큰 탈취 시 보안 위협, 토큰의 유효기간 및 갱신 관리 필요
4. OAuth와 OpenID Connect
- OAuth: 권한 부여를 위한 프레임워크로, 사용자가 다른 애플리케이션의 자원에 접근할 수 있도록 허용합니다. 주로 소셜 로그인(Naver, Kakao, Google, Apple 등)에 사용됩니다.
OpenID Connect: OAuth 2.0을 기반으로 한 인증 프로토콜로, 사용자의 ID를 확인하는 데 사용됩니다.
장점: 제3자 인증 제공, 다양한 인증 제공자와 통합 가능
단점: 복잡한 구현, 외부 인증 제공자에 의존합니다.
인증 구현 방법
1. 사용자 등록 (Sign-Up)
- 사용자는 애플리케이션에 처음 접근할 때 사용자명, 비밀번호, 이메일 등의 정보를 제공하여 계정을 생성합니다.
- 비밀번호는 반드시 해시 알고리즘(예: bcrypt, Argon2 / hash[good])을 사용하여 암호화된 형태에 솔트(salt)라는 개념을 더 하여 패스워드가 유출되더라도 복호화 할 수 없도록 데이터베이스에 저장해야 합니다.
2. 로그인 (Sign-In)
사용자가 로그인 폼을 통해 사용자명과 비밀번호를 입력하면 서버는 데이터베이스에서 사용자 정보를 조회하고, 제공된 비밀번호가 저장된 해시와 일치하는지 확인합니다.
일치하면 사용자가 인증된 것으로 간주하고, 토큰(JWT) 또는 세션 ID를 발급합니다.
3. 인증 토큰 발급
- 로그인에 성공한 사용자는 인증 토큰(JWT)을 발급받습니다. 이 토큰은 사용자가 이후 요청에서 인증을 위해 사용됩니다.
- JWT는 기본적으로 헤더(Header), 페이로드(Payload), 서명(Signature) 세 부분으로 구성되며, 사용자의 정보를 안전하게 전달할 수 있습니다.
- 토큰은 클라이언트 측(Local Storage, Cookie 등)에 저장됩니다.
4. 요청 검증
- 클라이언트가 서버에 요청을 보낼 때마다, 서버는 요청에 포함된 토큰을 검증하여 사용자가 인증된 상태인지 확인합니다.
- 토큰이 유효하고 만료되지 않았으며, 서버의 서명과 일치하는지 확인한 후 요청을 처리합니다.
5. 로그아웃
- 사용자는 로그아웃할 때 클라이언트 측에 저장된 토큰을 삭제하거나 무효화하여 인증을 종료합니다.
- 서버 측에서 JWT를 사용하는 경우, 별도의 상태를 저장하지 않으므로 로그아웃 시 추가 작업이 필요 없습니다. 세션 기반 인증에서는 서버에서 세션을 만료 처리해야 합니다.
인가
인가는 인증된 사용자가 특정 페이지에 접근할 때 권한을 가지고 있는지 확인하고 통행증을 확인하여 지나갈 수 있음을 부여하는 과정입니다.
예시로 일반 유저 티켓과 운영자 티켓이 분리가 된다면 운영자 티켓은 일반 유저 공간과 운영자 공간 두 곳을 모두 확인할 수 있도록 인가하지만, 일반 유저가 운영자 공간을 마음대로 입장하지 못하도록 인가하지 않는다.로 정의할 수 있습니다.
1. 권한 정의 및 할당
- 애플리케이션의 각 기능에 필요한 권한을 정의하고, 각 사용자의 역할 또는 속성에 따라 권한을 할당합니다.
- RBAC를 사용할 경우, 사용자는 여러 역할을 가질 수 있으며, 각 역할은 여러 권한을 포함할 수 있습니다.
2. 인가 미들웨어 또는 필터 설정
- 애플리케이션의 요청 처리 파이프라인에서 인증이 완료된 후, 인가를 수행하기 위해 미들웨어(또는 필터)를 설정합니다.
- 미들웨어는 사용자의 역할이나 권한을 확인하고, 요청된 자원에 접근할 수 있는지 결정합니다.
3. 정책 평가
- ABAC 또는 PBAC를 사용하는 경우, 정책 엔진을 통해 사용자의 속성, 자원의 속성, 환경 조건 등을 평가하여 접근을 허용하거나 거부합니다.
4. 접근 허용 또는 거부
- 요청된 자원에 대한 접근이 허용되면, 요청을 계속 처리하고, 그렇지 않으면 403 Forbidden 응답을 반환합니다.
이것으로 가볍게 인증(Authentication)과 인가(Authorication)에 대해 정리해 봤습니다.
오타나 부족한 정보가 있다면 언제든지 댓글로 알려주시면 감사드리겠습니다. 다음 포스트에서 뵙겠습니다.