API와 JWT
API(Application Programing Interface)
사전적 의미
- API : 응용 프로그램에서 사용할 수 있도록, 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻한다.
- 인터페이스 : 컴퓨터 시스템끼리 정보를 교한하는 공유 경계를 의미, 어떤 기계간의 장치끼리 정보를 교환하기 위한 수단이나, 방법을 의미
풀어서 보면 API는 어떠한 응용프로그램에서 데이터를 주고 받기 위한 방법을 의미
어떤 특정 사이트에서 특정 데이터를 공유할 경우 어떠한 방식으로 정보를 요청해야 하는지, 그리고 어떠한 데이터를 제공 받을 수 있을지에 대한 규격들을 API라고 하는것
API는 점원과 같은 역할
API는 손님(프로그램)이 주문할 수 있게 메뉴(명령 목록)를 정리하고, 주문(명령)을 받으면 요리사(응용프로그램)(API 제공자. 기상청, 공공포탈 등)와 상호작용하여 요청된 메뉴(명령에 대한 값)를 전달
손님은 주방에서 무슨 일이 일어나는지 잘 모른다. 대개는 관심도 없으며 관심을 가질 필요도 딱히 없다. 이것이 API의 장점이다. 내가 가져다쓰려는 API의 기능을 어떻게 구현하는지 몰라도 되고 난 그저 API가 갖다주는 걸 사용만 하면 된다(식사한다)는 것이다. 시간과 노력을 동시에 아낄 수 있다. 이처럼 API는 처음부터 개발하거나 유지 보수할 필요가 없는 외부 데이터와 기능에 접속할 수 있게 해준다.
쉽게 말해, API는 프로그램들이 서로 상호작용하는 것을 도와주는 매개체
API의 역할
1. API는 서버와 데이터베이스에 대한 출입구 역할을 한다.
- API는 서버와 데이터베이스에 대한 출입구 역할을 하며, 허용된 사람들에게만 접근성을 부여해줍니다.
2. API는 애플리케이션과 기기가 원활하게 통신할 수 있도록 한다.
- 애플리케이션이란 우리가 흔히 알고 있는 스마트폰 어플이나 프로그램을 말합니다. API는 애플리케이션과 기기가 데이터를 원활히 주고받을 수 있도록 돕는 역할을 합니다.
3. API는 모든 접속을 표준화한다.
- API는 모든 접속을 표준화하기 때문에 기계/ 운영체제 등과 상관없이 누구나 동일한 액세스를 얻을 수 있습니다. 쉽게 말해, API는 범용 플러그처럼 작동한다고 볼 수 있습니다.
API의 유형
private API
- private API는 내부 API로, 회사 개발자가 자체 제품과 서비스를 개선하기 위해 내부적으로 발행합니다. 따라서 제 3자에게 노출되지 않습니다.
public API
- public API는 개방형 API로, 모두에게 공개. 누구나 제한 없이 API를 사용할 수 있는 게 특징
partner API
- partner API는 기업이 데이터 공유에 동의하는 특정인들만 사용할 수 있습니다. 비즈니스 관계에서 사용되는 편이며, 종종 파트너 회사 간에 소프트웨어를 통합하기 위해 사용.
API의 장점
Private API를 이용할 경우,
개발자들이 애플리케이션 코드를 작성하는 방법을 표준화함으로써, 간소화되고 빠른 프로세스 처리를 가능하게 한다.
또한, 소프트 웨어를 통합하고자 할 때는 개발자들 간의 협업을 용이하게 만들어줄 수 있다.
public API와 partner API 를 사용하면,
기업은 타사 데이터를 활용하여 브랜드 인지도를 높일 수 있다.
뿐만 아니라 고객 데이터베이스를 확장하여 전환율까지 높일 수 있다.
API란? 비개발자가 알기 쉽게 설명해드립니다! - wishket
여러분은 API가 무엇인지 알고 계신가요? 자주 듣지만 그 개념이 무엇인지 정확하게 알기 쉽지 않은데요. 이번 시간 위시켓이 API란 무엇인지 알기 쉽게 설명해드리고자 합니다.
blog.wishket.com
[IT용어] API란 무엇인가? — Steemit
안녕하세요. 어미새입니다. 정말 오랜만에 스팀잇에 포스팅을 진행하는것 같습니다. 개인적으로 바쁜 일상을 보내고 있다보니, 1일 1포스팅이 아닌 1주 1포스팅도 어려운 상황이었습니다. 다시
steemit.com
봐도봐도 모르겠는 API 개념 설명 (Application Programming Interface)
✔️ 부정확한 내용이 포함되어 있다는 피드백을 받았습니다. 글은 나중에 다시 수정할 예정인데, 우선 댓글창을 확인해주시면 더 정확하게 이해하실 수 있을 것 같습니다. 감사합니다 ^^ 컴퓨
dev-dain.tistory.com
JWT
로그인 기능을 구현하는데에는 여러 방식이 존재함
1. 쿠키
2. 세션
3. 토큰
쿠키
쿠키란 클라이언트가 어떠한 웹사이트를 방문할 경우, 그 사이트가 사용되고 있는 서버를 통해 클라이언트의 브라우저에 설치되는 작은 기록 파일
쿠키 사용법
사용자는 서버에 사용자의 로그인 요청을 보낼때 마다 쿠키에 담긴 사용자 정보를 요청한다.
서버는 쿠키에 담긴 정보를 바탕으로 사용자가 누구인지 식별하여 사용자에게 맞는 정보를 응답한다.
쿠키의 단점
- 보안에 취약함(요청시 쿠키의 값을 그대로 보내어 유출, 조작 당할 위험이 있음)
- 용량 제한이 있어 많은 정보를 담지 못함
- 웹 브라우저 마다 쿠키에 대한 지원형태가 다르기에 브라우저간 공유가 불가능함
세션
사용자 인증 정보(아이디, 비밀번호 등)을 쿠키가 아닌 서버측에 저장하고 관리함
세션 사용법
서버는 사용자 정보를 서버측에 저장하고, 사용자가 서버에 사용자 식별자인 JSESSIONID를 쿠키에 담아서 로그인 요청을 보내면 서버 세션에서 JSESSIONID를 이용해 사용자 정보를 확인해 맞으면 사용자에게 맞는 정보를 응답함
세션의 장점
- 각 사용자마다 고유한 세션 ID가 발급되기 때문에, 요청이 들어올 때마다 회원 정보를 확인(로그인)할 필요 없다.
- JSESSIONID인 쿠키를 사용하지만 안에는 유의미한 개인 정보가 담기지 않아 보안이 조금 더 높다.
세션의 단점
- 다른 사용자가 세션ID를 탈취하여 다른 사용자인척 위장 할 수 있다.
- 서버에서 세션 저장소를 따로 운용하기 때문에 추가적인 비용부분이 생기며, 요청이 많으면 서버에 부하가 생긴다.
토큰
토큰 기반 인증(JWT)
JWT(JSON Web Token)은 인증에 필요한 정보들을 암호화 시킨 토큰이다.
JWT 방식은 쿠키와 세션과 유사하지만, 정보를 암호화 시킨다는 차이가 있음
사용자가 JWT 토큰을 암호화 하여 쿠키에 담아 보내면 서버에서 토큰을 디코딩(해독)하여 사용자 정보를 확인하여 응답한다.
JWT의 구조는 세가지 문자열의 조합이다.
header, payload, signature 로 이루어져 있다.
Header
Header는 alg, typ을 갖고 있음
alg는 정보를 암호화 할 해싱 알고리즘
typ은 토큰의 타입
{
"alg": "HS256",
"typ": "JWT"
}
Payload
Payload는 실제로 토큰에 담을 정보를 지니고 있음
주로 사용자 고유 ID, 유효기간 등이 포함됨
{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516230922
}
Signature
Signature는 인코딩된 header 와 payload를 더한 뒤, 비밀키로 해싱하여 생성
Header 및 Payload는 단순 인코딩된 값이기 때문에 해커가 복호화하고 조작할 수 있지만, Signature는 서버 측에서 관리하는 비밀키가 유출되지 않는 이상 복호화할 수 없음
따라서 Signature는 토큰의 위변조 여부를 확인 하는데 사용
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret_key
)
토큰 인증 과정
- 클라이언트 로그인 요청이 들어오면, 서버는 검증 후 클라이언트 고유 ID등의 정보를 Payload에 담는다.
- 암호화할 비밀키를 사용해 Access Token(JWT)을 발급한다.
- 클라이언트는 전달받은 토큰을 쿠키에 저장해두고, 서버에 요청할 때마다 토큰을 요청 헤더 Authorization에 포함시켜 함께 전달한다.
- 서버는 토큰의 Signature 을 비밀키로 복호화한 다음, 위변조 여부 및 유효 기간 등을 확인한다.
- 유효한 토큰이라면 요청에 응답한다.
토큰의 장점
- Header와 Payload를 가지고 Signature를 생성하므로 데이터 위변조를 막을 수 있다.
- 인증 정보에 대한 별도의 저장소가 필요 없다. (I/O 처리 필요 없음)
- JWT는 토큰에 대한 기본 정보와 전달할 정보 및 토큰이 검증됐음을 증명하는 서명 등 필요한 모든 정보를 자체적으로 지니고 있다.
- 클라이언트의 인증 정보를 저장하는 세션과 다르게, 서버는 무상태(Stateless)가 된다.
- 확장성이 우수하다.
- 토큰 기반으로 다른 로그인 시스템에 접근 및 권한 공유가 가능하다. (토큰 서버 활용)
- 토큰 기반으로 다른 로그인 시스템에 접근 및 권한 공유가 가능하다.
- OAuth의 경우 Facebook, Google 등 소셜 계정을 이용해 다른 웹서비스에서도 로그인 할 수 있다.
- 모바일 어플리케이션 환경에서도 잘 동작한다.
토큰의 단점
- 쿠키, 세션과 다르게 JWT는 토큰의 길이가 길어, 인증 요청이 많을수록 네트워크 부하가 심해진다.
- Payload 자체는 암호화되지 않기 때문에 유저의 중요한 정보는 담을 수 없다. (패스워드 등)
패스워드는 보안성을 높이기 위해 서버에 저장할때 알고리즘으로 암호화하여 저장하면 보안성을 높일 수 있음(필수)
- 토큰을 탈취당하면 대처하기 어렵다. 토큰은 한 번 발급되면 유효기간이 만료될 때까지 계속 사용이 가능하다.
- 특정 사용자의 접속을 강제로 만료하기 어렵다. (쿠키/세션 기반 인증은 서버 단에서 쉽게 삭제할 수 있지만 토큰은 그게 안 됨)
토큰의 보안성을 높이는 방법
1. 비밀번호 암호화
payload에 사용자의 정보가 그대로 담기기 때문에 비밀번호 같은 중요한 정보는 데이터를 저장 및 사용 할때 알고리즘으로 로 한번더 해싱 하여 보안성을 높임
2. 만료 기간을 짧게 설정
토큰의 만료 기한을 짧게 설정해서 탈취되더라도 빠르게 만료시키는 방법
하지만 이는 토큰이 만료되면 사용자가 다시 로그인해야 한다는 뜻이기에 사용자 입장에서 번거로운 방법
만료기간이 짧으면 보안성은 높아지나, 사용자가 매번 로그인을 다시해야하는데 이를 해결하는 방법이 있다.
Sliding Session
서비스를 지속적으로 이용하는 클라이언트에게 자동으로 토큰 만료 기한을 늘려주는 방법
만약 글을 작성하다가 토큰이 만료된다면 새로운 토큰을 발급하여 사용자가 로그인을 자주 할 필요가 없음
Refresh Token
클라이언트가 로그인할 때 Access Token 및 Refresh Token을 발급해주는 방법
Refresh Token : Access Token보다 만료 기한이 긴 토큰
클라이언트가 요청을 보냈는데 Access Token이 만료되었을 때, Refresh Token을 이용하여 Access Token의 재발급을 요청
이때 서버는 DB에 저장된 Refresh Token과 비교하여 유효하면 Access Token을 발급
만약 Refresh Token도 만료된 경우라면 사용자에게 로그인을 요구
이 전략을 사용하면 Access Token의 만료 기한을 짧게 설정하여 위의 짧은 만료 기한 설정 전략처럼 탈취되더라도 빠르게 만료될 수 있어 추가 보안문제를 해결
또한 짧은 만료 기한에도 불구하고 자주 로그인을 할 필요가 없다. 서버가 강제로 Refresh Token을 만료시킬 수도 있다.
쿠키, 세션, 토큰(JWT) 몰라도 괜찮겠어?
깔끔하게 정리했으니 몇 분만 투자해서 이번 기회에 바로 알고 가기 😀
velog.io
'coding > JS' 카테고리의 다른 글
| slice()와 splice() 차이 (0) | 2022.07.19 |
|---|---|
| slice, 정규식 (0) | 2022.07.18 |
| filter, set, replace (0) | 2022.07.17 |
| map (0) | 2022.07.16 |
| 회원가입 유효성 검사 (0) | 2022.05.06 |