반응형

신용카드 식별 번호(BIN, Bank Identification Number)

신용카드와 체크카드 번호는 XXXX-XXXX-XXXX-XXXX 형식으로 4자리씩 총 16자리로 구성된다. 아멕스 신용카드 처럼 일부 카드는 15자리도 있지만 대부분은 16자리이다.
이 중에서 앞자리 6개는 국제식별번호이며 BIN (Bank Identification Number) 이라고 부른다.

이 6자리 숫자에 카드 브랜드, 카드의 종류(법인카드/개인카드, 체크카드/신용카드/직불카드/선불카드/기프트카드), 카드등급(플래티늄, 골드, 우량, 일반), 발행금융사와 발행 국가에 대한 정보가 모두 들어 있으며, 일반적으로 맨 앞자리 4개는 브랜드이고 뒤에 2개는 금융기관 코드이다.

앞의 6자리 외에 그 뒷부분의 숫자는 각 금융기관들이 사용하는 내부코드이고, 맨 마지막은 검증숫자이다.

따라서, 동일한 카드, 같은 브랜드, 같은 등급, 같은 종류의 카드를 발급받은 사람은 앞자리 6개는 똑같다. 예를 들면, 요즘 인기있는 카카오뱅크 체크카드는 마스터카드 브랜드일 경우 5365 10 으로 시작하고, 국내전용 카드이면 9490 99  로  누구나 6자리 번호가 똑같게 된다. (일반 신용카드는 Platinum, Gold, Silver 등급이 더 세분화되서 번호가 다른 경우가 많은데 카뱅은 단순 등급 밖에 없다)

전세계 워낙 많은 신용카드사가 있어 숫자가 충돌될 수도 있기에 해외 승인이 가능한 Visa, Master 카드 같은 것은 세계공통 BIN 번호 규칙성을 갖는다.
우리나라에서 많이 쓰는 카드를 기준으로 BIN번호 대충 정리하면 아래와 같다.

* 356X : JCB카드
* 36XX : 다이너스카드 (Diners Club International)
* 37XX : 아멕스(아메리칸 익스프레스, American Express)
* 4XXX : 비자카드 (Visa)
* 51XX ~ 55XX : 마스터카드 (Master) 
                            (5천대 외에 2221 ~ 2720 신규 대역을 17년도부터 추가 예정)
* 62XX : UnionPay 중국은련카드 (CUP, China UnionPay)
* 65XX : BC카드 글로벌 (BC Global)
* 9XXX : 각 국가별 국내 전용카드 (Local 카드)
    9035 xx : 제주은행
    9100 xx, 9200 xx, 9300 xx : BC카드
    9407 xx : 수협카드
    9409 xx : 롯데카드
    9410 xx : 신한카드, BC카드, 삼성카드, KB카드, 하나카드 ....  뒤죽박죽...
    9490 xx : 현대카드, 전북은행, KB카드, ...  뒤죽박죽 ...



제일 많이 쓰는 비자(Visa) 브랜드 제휴카드의 경우 4로 시작하고, 마스터(Master) 제휴카드는 51~55로 시작하고, 만약 연회비가 비싸서 그냥 국내카드로 신청하면 9로 시작하는 국내카드용 번호가 부여되는 식이다.
9천번대 국내전용 카드는 옛날에는 기관코드 규칙성이 있어서 어느 회사 카드인지 대충 알아볼 수 있었으나, IMF이후 수많은 카드사와 은행이 합병, 분할, 재분사 등을 하다보니 이제는 엉망진창이 되어 규칙성이 거의 사라져서 뒤죽박죽이 되버렸다.

국내 신용카드사 전체의 6자리 BIN 넘버를 알고 싶으면, VAN사 자료실에서 찾아보면 된다.

1) KICC 한국정보통신
    https://www.kicc.co.kr/kr/support/pds/van/pds_van_list.jsp?s_menu=4&t_menu=1
2) KSNET
    https://www.ksnet.co.kr/Bbs?ci=NOTICE&c=NOTICE&fi=&fw=&f=ALL&q=BIN


BIN 번호를 활용하는 사례는,
통신사 요금 신용카드로 자동이체 신청할 때, 쇼핑몰에서 결제할 때 신용카드 번호를 입력하면 어느 순간 자동으로 무슨 카드인지 보여주는 경우가 있는데 이 6자리 BIN번호를 가지고 판단하는 것이다.

KTX 철도 예약이나 역 창구 현장에서 결제할 때 무슨 체크카드는 되는데 무슨 체크카드는 안되고 이런 것은 카드결제하는 순간 이 6자리 BIN을 검사해서 그 회사의 카드는 승인거절 하는 것이다. 현재 롯데카드 체크카드와 시티카드 체크카드는 무슨 이유인지 몰라도 대부분 결제가 안된다.

해외 브랜드 공홈에서 직구할 때도 한국에서 구매를 못하게 막아놓는 경우가 있는데, 이때 보통은 배송지 주소와 신용카드 청구지주소(Billing Address)가 일치하는지 검사하거나, 유명한 배대지 주소를 막는 경우가 많지만, BIN 번호를 검사해서 이게 한국에서 발급한 신용카드이면 승인을 막아버리는 경우도 있다.

해외에서 발급받은 카드로 국내에서 이용하려고 하면 역시 BIN번호 검사해서 승인 거절하는 곳도 많다. 이것은 외국인이 결제한 내역을 승인취소하고 환불하고 하는 과정이 매우 귀찮고, 또 만약 위조된 가짜 신용카드를 가지고 사기치면 이를 적발해서 신고하고, 환급하고 하는 과정이 거의 불가능이기 때문에 귀찮아서 아예 승인자체를 막아놓는 것이다.


카드 번호 검증코드 (Check Digit)

위에서 설명한 것 처럼 카드번호의 맨 마지막 숫자는 카드번호의 검증코드이다.
카드번호 총 16자리 숫자에서(아멕스카드는 15자리) 검증번호 체계는 다음처럼 계산한다.

 1) 마지막 검증코드숫자를 제외하고 그 앞 숫자부터 거꾸로 가면서 2를 곱하고, 그다음은 1을 곱하고, 다시 2와 1 곱하기를
     번갈아 나열해서 곱한다.
2) 곱셈한 결과가 10을 넘을 경우 다시 숫자끼리 더한다.
    - 예를 들어 7*2 = 14 일 경우 다시 1+4 = 5 로 치환한다.
3) 모든 숫자의 계산 결과를 모두 더한다.
4) 합계 숫자의 끝자리 수를 10에서 빼면 검증코드 숫자이다.  끝자리 수가 0인 경우 그냥 0이다.
    - 예를 들어 합계 숫자가 62이면, 끝자리는 2이고, 검증코드는 10-2= 8이 된다.  합계숫자가 50이면 검증코드는 0이다.

카드번호가 4579-7300-7124-7055  인 경우 계산해보자.
맨끝의 검증숫자 바로 앞의 숫자부터 2, 1, 2, 1 ...  을 곱해주고 위 설명대로 계산해보면,

마지막 4번째 계산된 결과를 모두 합하면 합계는 55이다.
55에서 일자리 끝숫자는 5 이고,  10에서 5를 빼면 5가 된다.  카드번호 제일 끝자리 검증코드 5와 같으므로 유효한 카드번호이다.
(또는 다르게 풀면, 계산된 합계 55와 마지막 검증숫자 5을 합친 숫자는 반드시 10의 배수여야 한다.)

이 검증규칙을 이용해서 카드번호를 엉터리로 집어넣으면 카드번호가 틀렸다고 나오면서 다시 입력하라고 나오게 된다.


보안코드 (card security code)

한편, 위 검증코드는 단순히 신용카드 번호 입력할 때 틀렸는지 숫자의 유효성만 검사하는 것이고,
상점에서의 직접 거래가 아닌 비대면 거래, 즉, 카드번호만으로 온라인 결제하는 경우 보안강화를 위해서 카드 보안코드 3자리가 있다.
회사마다 호칭이 다른데 비자카드는 CVV, 마스타/JCB는 CVC, 아멕스는 CID라고 부른다.
카드 뒷면을 보면 서명하는 곳에 작은 글씨로 숫자 3자리가 써있는 그것이다.

특이하게, 아멕스 카드는 뒷면이 아니라 앞면에 4자리의 카드보안코드가 있는데, 만약 순수 아멕스 카드가 아니라 국내 카드사의 제휴된 아멕스카드일 경우 국내 보안프로그램인 일반결제(안심클릭)나 ISP 등록을 위해서 앞면 4자리 숫자말고 뒷면에도 국내용 CID 3자리가 또 있다.
보통 아마존 같은 해외 직구할 때나 국내 쇼핑몰에서 안심클릭 입력할 때 어느 숫자를 넣으라고 알려주니 헷갈리지 말고 입력하면 된다.

보안코드의 검증 규칙은 카드사 내부 기밀이라서 알 수 없다.


* 기타 자료

* 전세계 BIN 번호체계를 좀 더 자세히 알고 싶으면 위키에서 보시길 ... (영문사이트)
https://en.wikipedia.org/wiki/Payment_card_number

Payment card number - Wikipedia

Contents 1 Structure 2 Issuer identification number (IIN) 2.1 Canadian bank card numbering 3 Security measures 4 References 5 External links Structure [ edit ] The leading six digits of the card number is the " issuer identification number (IIN)", sometimes referred to as the "bank id

en.wikipedia.org

* 아래 주소에 가서 신용카드 앞자리 6개만 입력해보면, 발생 회사와 등급 등을 간단하게 볼 수 있다.
외국 사이트라서 간혹 잘못된 정보가 나오기도 하니 단순히 재미삼아 해보기 바랍니다.
https://binlist.net/

 

출처 : https://m.blog.naver.com/mumasa/221121389505

반응형

'Web > etc.' 카테고리의 다른 글

[OS및 브라우저별 userAgent값]  (1) 2020.04.06
Token, JWT, OAuth  (0) 2020.03.29
반응형

[OS및 브라우저별 userAgent값]

 

Windows XP IE8  (IE7모드로 호환성보기)

           Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0;

 

Windows XP IE8  (IE8 모드로 보기)

           Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0;

 

Windows Vista IE8 (IE7모드로 호환성보기)

           Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; Trident/4.0)

 

Windows Vista IE8 (IE8 모드로 보기)

           Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0)

 

IE8 on Windows 7 (Window 7 에서 IE8)

           Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0)

 

64-bit IE on 64-bit Windows: (64bit 비스타에서 64bit IE8)

           Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Win64; x64; Trident/4.0)

 

32-bit IE on 64-bit Windows: (64bit 비스타에서 32bit IE8)

           Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; WOW64; Trident/4.0)

 

IE11 on Windows 7

   Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko

 

IE11 on 64-bit Windows 8.1 Update

   Mozilla/5.0 (Windows NT 6.3; Win64, x64; Trident/7.0; Touch; rv:11.0) like Gecko

 

IE11 for the desktop on 64-bit Windows 8.1 Update

   Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; Touch; rv:11.0) like Gecko

 

IE11 for the desktop on 64-bit Windows 8.1 Update with enterprise mode enabled

 

  Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; Tablet PC 2.0)

 

IE11 for the desktop on 64-bit Windows 8.1 Update with compatibility view enabled

   Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.3; Trident/7.0; Touch)

 

Microsoft Edge for Windows 10 Insider Preview

   Mozilla/5.0 (Windows NT 6.3; Trident/7.0; rv:11.0) like Gecko

 

Microsoft Edge for Windows Phone

   Mozilla/5.0 (Windows Phone 10.0; Android 4.2.1; DEVICE INFO) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.71 Mobile Safari/537.36 Edge/12.0

 

Internet Explorer for Windows Phone 8.1 Update

   Mozilla/5.0 (Mobile; Windows Phone 8.1; Android 4.0; ARM; Trident/7.0; Touch; rv:11.0; IEMobile/11.0; NOKIA; Lumia 520) like iPhone OS 7_0_3 Mac OS X AppleWebKit/537 (KHTML, like Gecko) Mobile Safari/537

 

IE11 on a Lumia 928 running Windows Phone 8.1, mobile version

 

   Mozilla/5.0 (Windows Phone 8.1; ARM; Trident/7.0; Touch; rv:11;

 

 IEMobile/11.0; NOKIA; Lumia 928) like Gecko

   IE on a Lumia 920 running Windows Phone 8.0, mobile version

 

Mozilla/5.0 (compatible; MSIE 10.0; Windows Phone 8.0; Trident/6.0; 

 

   IEMobile/10.0; ARM; Touch; rv:11; NOKIA; Lumia 920) like Gecko

 

IE on a Lumia 920 running Windows Phone 8.0, desktop version

   Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0; ARM; Touch; WPDesktop)

 

IE on Xbox One

   Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0; Xbox; Xbox One)

 

IE on Xbox 360

   Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0; Xbox)

 

[자바스크립트]

<script>

var agent = navigator.userAgent.toLowerCase(); //현재 브라우저 정보를 소문자로 받아온다.

if(agent.indexOf("windows nt 5.1") >= 0) // OS 식별

alert("Windows XP");

else if(agent.indexOf("windows nt 6.0") >=0)

alert("Windows Vista");

else if(agent.indexOf("windows nt 6.1") >= 0)

alert("Windows 7");

else if(agent.indexOf("windows nt 6.3") >= 0) // windows 10

alert("windows 10");

else if(agent.indexOf("windows phone 8.1") >= 0)

alert("Windows Phone 8.1");

else if(agent.indexOf("windows PHONE 10.0") >= 0)

alert("Windows Phone 10.0");

else if(agent.indexOf("android") >= 0 )

alert("Android");

else if(agent.indexOf("iphone") >= 0 )

alert("IPhone");

else if(agent.indexOf("ipad") >= 0 )

alert("IPad");

else if(agent.indexOf("ipod") >= 0 )

alert("IPod");

else if(agent.indexOf("mac") >= 0 )

alert("mac");

else

alert(agent);

 

if(agent.indexOf("msie 7") >= 0) // 브라우저 식별

alert("IE 7");

else if(agent.indexOf("msie 8") >= 0)

alert("IE 8");

else if(agent.indexOf("msie 9") >= 0)

alert("IE 9");

else if(agent.indexOf("msie 10") >= 0) // IE 10

if(agent.indexOf("Touch") >= 0) // IE10 on a machine with touch-capable hardware

alert("IE 10 on Touch");

else

alert("IE 10");

else if(agent.indexOf("rv:11.0") >= 0)

alert("IE 11");

else if(agent.indexOf("edge/12.0") >= 0)

alert("Spartan");

else if(agent.indexOf("chrome") >= 0)

alert("Chrome");

else if(agent.indexOf("safari") >= 0)

alert("Safari");

else if(agent.indexOf("firefox") >= 0)

alert("Firefox");

else if(agent.indexOf("opera") >= 0)

alert("Opera");

else

alert(agent);

 

if(agent.indexOf("win64") >= 0) // 처리방식 식별

alert("64bit")

else if(agent.indexOf("wow64") >= 0)

alert("32-bit IE on 64-bit");

else if(agent.indexOf("arm") >= 0)

alert("Windows RT");

else

alert("32bit");

 

</script>

 

출처 : http://soke.tistory.com/3

반응형

'Web > etc.' 카테고리의 다른 글

신용카드 번호 체계(BIN)와 검증번호  (0) 2020.06.02
Token, JWT, OAuth  (0) 2020.03.29
반응형

* Token

프로그래밍 언어에서의 토큰은, 문법적으로 더 이상 나눌 수 없는 기본적인 언어요소를 말하는데, 예를 들어 하나의 키워드나 연산자 또는 구두점 등이 토큰이 될수 있다.

 

토큰 기반 시스템의 작동 원리

토큰 기반 시스템은 stateless 합니다. 무상태. 즉 상태유지를 하지 않는다는 것이죠. 이 시스템에서는 더 이상 유저의 인증 정보를 서버나 세션에 담아두지 않습니다. 이 개념 하나만으로도 위에서 서술한 서버에서 유저의 인증 정보를 서버측에 담아둠으로서 발생하는 많은 문제점들이 해소됩니다.

세션이 존재하지 않으니, 유저들이 로그인 되어있는지 안되어있는지 신경도 쓰지 않으면서 서버를 손쉽게 확장 할 수 있겠죠?

토큰 기반 시스템의 구현 방식은 시스템마다 크고작은 차이가 있겠지만, 대략적으로 보면 다음과 같습니다:

  1. 유저가 아이디와 비밀번호로 로그인을 합니다
  2. 서버측에서 해당 계정정보를 검증합니다.
  3. 계정정보가 정확하다면, 서버측에서 유저에게 signed 토큰을 발급해줍니다.
    여기서 signed 의 의미는 해당 토큰이 서버에서 정상적으로 발급된 토큰임을 증명하는 signature 를 지니고 있다는 것입니다
  4. 클라이언트 측에서 전달받은 토큰을 저장해두고, 서버에 요청을 할 때 마다, 해당 토큰을 함께 서버에 전달합니다.
  5. 서버는 토큰을 검증하고, 요청에 응답합니다.

웹서버에서 토큰을 서버에 전달 할 때에는, HTTP 요청의 헤더에 토큰값을 포함시켜서 전달합니다.

토큰의 장점

무상태(stateless) 이며 확장성(scalability)이 있다

이 개념에 대해선 지금 반복적으로 이야기하고 있죠? 이는 그만큼 토큰 기반 인증 시스템의 중요한 속성입니다. 토큰은 클라이언트사이드에 저장하기때문에 완전히 stateless 하며, 서버를 확장하기에 매우 적합한 환경을 제공합니다. 만약에 세션을 서버측에 저장하고 있고, 서버를 여러대를 사용하여 요청을 분산하였다면, 어떤 유저가 로그인 했을땐, 그 유저는 처음 로그인했었던 그 서버에만 요청을 보내도록 설정을 해야합니다. 하지만, 토큰을 사용한다면, 어떤 서버로 요청이 들어가던, 이제 상관이 없죠.

보안성

클라이언트가 서버에 요청을 보낼 때, 더 이상 쿠키를 전달하지 않음으로 쿠키를 사용함으로 인해 발생하는 취약점이 사라집니다. 하지만, 토큰을 사용하는 환경에서도 취약점이 존재 할 수 있으니 언제나 취약점에 대비해야 합니다(참조).

Extensibility (확장성)

여기서의 확장성은, Scalability 와는 또 다른 개념입니다. Scalability 는 서버를 확장하는걸 의미하는 반면, Extensibility 는 로그인 정보가 사용되는 분야를 확장하는것을 의미합니다. 토큰을 사용하여 다른 서비스에서도 권한을 공유 할 수 있습니다. 예를 들어서, 스타트업 구인구직 웹서비스인 로켓펀치에서는 Facebook, LinkedIn, GitHub, Google 계정으로 로그인을 할 수 있습니다. 토큰 기반 시스템에서는, 토큰에 선택적인 권한만 부여하여 발급을 할 수 있습니다 (예를들어서 로켓펀치에서 페이스북 계정으로 로그인을 했다면, 프로필 정보를 가져오는 권한은 있어도, 포스트를 작성 할 수 있는 권한은 없죠)

여러 플랫폼 및 도메인

서버 기반 인증 시스템의 문제점을 다룰 때 CORS 에 대하여 언급 했었죠? 어플리케이션과 서비스의 규모가 커지면, 우리는 여러 디바이스를 호환 시키고, 더 많은 종류의 서비스를 제공하게 됩니다. 토큰을 사용한다면, 그 어떤 디바이스에서도, 그 어떤 도메인에서도, 토큰만 유효하다면 요청이 정상적으로 처리 됩니다. 서버측에서 어플리케이션의 응답부분에 다음 헤더만 포함시켜주면 되지요.

Access-Control-Allow-Origin: *

이런 구조라면, assets 파일들(이미지, css, js, html 파일 등)은 모두 CDN 에서 제공을 하도록 하고, 서버측에서는 오직 API만 다루도록 하도록 설계 할 수도 있지요.

웹 표준 기반

토큰 기반 인증 시스템의 구현체인 JWT는 웹 표준 RFC 7519 에 등록이 되어있습니다. 따라서 여러 환경에서 지원이 되며 (.NET, Ruby, Java, Node.js, Python, PHP …) 수많은 회사의 인프라스트럭쳐에서 사용 되고 있습니다 (구글, 마이크로소프트 …)

출처 : https://velopert.com/2350

 

JWT란? 

기본 정보

JSON Web Token (JWT) 은 웹표준 (RFC 7519) 으로서 두 개체에서 JSON 객체를 사용하여 가볍고 자가수용적인 (self-contained) 방식으로 정보를 안전성 있게 전달해줍니다.

수많은 프로그래밍 언어에서 지원됩니다

JWT 는 C, Java, Python, C++, R, C#, PHP, JavaScript, Ruby, Go, Swift 등 대부분의 주류 프로그래밍 언어에서 지원됩니다.

자가 수용적 (self-contained) 입니다

JWT 는 필요한 모든 정보를 자체적으로 지니고 있습니다. JWT 시스템에서 발급된 토큰은, 토큰에 대한 기본정보, 전달 할 정보 (로그인시스템에서는 유저 정보를 나타내겠죠?) 그리고 토큰이 검증됐다는것을 증명해주는 signature 를 포함하고있습니다.

쉽게 전달 될 수 있습니다

JWT 는 자가수용적이므로, 두 개체 사이에서 손쉽게 전달 될 수 있습니다. 웹서버의 경우 HTTP의 헤더에 넣어서 전달 할 수도 있고, URL 의 파라미터로 전달 할 수도 있습니다.



 Json Web Token : JWT 는 JSON Web Token의 약자로 전자 서명 된 URL-safe (URL로 이용할 수있는 문자만 구성된)의 JSON입니다.

 

일반 JSON에서는 발급된 토큰의 만료를 시킬 수단이 없고, 관리할 수 있는 방법이 없다.
그래서 클레임* 기반 토큰으로 발급한다.

 JWT 구조는 헤더, 페이로드, 서명으로 되어있다.

헤더에는 토큰타입과 암호 알고리즘 정보가 있다.
(헤더를 암호화 하는게 아니다. 토큰 검증시 사용.)
페이로드에는 클레임에 관한 정보들이 있다. (Base64로 인코딩한다. 암호화가 아니다)
서명에는 누구나 위변조 할수 있기 때문에 Signature부분이 있다.
 JSON 헤더랑 JWT Claim Set(페이로드)만으로 encode를 한다면 누구나 다시 이값을 decode할수가 있기 때문이다.
출처: https://gist.github.com/LeoHeo/c9678154b1dadd85add5862b30e969f8

 

그래서 시크릿키와 함께 만든다. 시크릿키가 있으면 복호화할 수 없다.
출처 : https://tansfil.tistory.com/58

JWT 의 생김새

JWT 는 . 을 구분자로 3가지의 문자열로 되어있습니다. 구조는 다음과 같이 이루어져있습니다:


1. Header
 

typ: 토큰의 타입을 지정합니다. 바로 JWT 이죠.

alg: 해싱 알고리즘을 지정합니다.  해싱 알고리즘으로는 보통 HMAC SHA256 혹은 RSA 가 사용되며, 이 알고리즘은, 토큰을 검증 할 때 사용되는 signature 부분에서 사용됩니다.

2. Payload

토큰에 담을 정보가 들어있습니다. 여기에 담는 정보의 한 ‘조각’ 을 클레임(claim) 이라고 부르고, 이는 name / value 의 한 쌍으로 이뤄져있습니다. 토큰에는 여러개의 클레임 들을 넣을 수 있습니다.

클레임 의 종류는 다음과 같이 크게 세 분류로 나뉘어져있습니다:

등록된 (registered) 클레임,
공개 (public) 클레임,
비공개 (private) 클레임

3. 서명(signature)
이 서명은 헤더의 인코딩값과, 정보의 인코딩값을 합친후 주어진 비밀키로 해쉬를 하여 생성합니다.

출처: https://velopert.com/2389

 


JWT를 사용하는 이유?


Cors를 해결하기 위해 사용한다.
Web, Mobile 등 다양한 클라이언트를 지원해야하는 경우 생김
스케일 아웃했을 때 서버마다 다른 세션 파일이 생성됨
등등 아래 출처에서 자세히  볼 수 있다.
출처 :https://sanghaklee.tistory.com/47


만약에 Android / iOS 모바일 어플리케이션을 개발 한다면, 안전한 API 를 만들기 위해선 쿠키같은 인증시스템은 이상적이지 않습니다. (쿠키 컨테이너를 사용해야하죠). 토큰 기반 인증을 도입한다면, 더욱 간단하게 이 번거로움을 해결 할 수 있습니다.

 토큰은 클라이언트사이드에 저장하기때문에 완전히 stateless 하며, 서버를 확장하기에 매우 적합한 환경을 제공합니다


https://velopert.com/2350


JWT 장단점



장점 : 상태가 필요하지 않다 (Stateless)
단점 : JWT는 한 번 발급되면 돌이킬 수 가 없다 (만료기간까지 계속 이용가능)
암호화하지않고 인코딩하기때문에 페이로드 정보가 제한적이다.
JWT의 길이가 길어서 인증 요청이 많아질 수록 서버의 자원낭비가 생길수 있다.(이건 크기를 보고 따로 확인해봐야할 사항)

출처 :https://sanghaklee.tistory.com/47


Refresh Token



탈취 당할경우 보안에 취약, 유효기간을 늘릴 수 없음.
짧으면 자주 발급받아야함.

그래서 처음에 로그인을 완료했을 때 Access Token과 동시에 발급되는 Refresh Token같이 만들어줌.

Refresh Token 은 긴 유효기간을 가지면서,  Access Token이 만료됐을 때 새로 발급해주는 열쇠가 됨

왜 쓰는지 아직 이해 못함
출처 : https://tansfil.tistory.com/59?category=255594

* 클레임 : 사용자 정보나 데이터 속성들을 의미한다.
출처 : https://elfinlas.github.io/2018/08/12/whatisjwt-01/

 

JWT(JSON Web Token) 이란?

인증과 토큰 그리고 JWT?최근들어 보안 및 인증을 위해서 JWT를 사용하게 되었다.그래서 사용만 하다가 이번에 JWT에 대한 개념과 구조, 사용법과 문제점 등을 알아보고자 한다. 일반 토큰 기반의 인증과 클레임(Claim) 토큰 기반 인증일반 토큰 기반은 과거에 많이 사용하던 방식이다.주로 의미가 없는 문자열(Random string) 기반으로 구성되어

elfinlas.github.io





OAuth

인증정보를 다른 어플리케이션으로 전달


OAuth는 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준이다.[1] 이 매커니즘은 여러 기업들에 의해 사용되는데, 이를테면 아마존,[2] 구글, 페이스북, 마이크로소프트, 트위터가 있으며 사용자들이 타사 애플리케이션이나 웹사이트의 계정에 관한 정보를 공유할 수 있게 허용한다.


출처 : https://ko.wikipedia.org/wiki/OAuth


OAuth는 Open Authorization, Open Authentication 뜻하는 것으로 애플리케이션(페이스북,구글,트위터)(Service Provider)의 유저의 비밀번호를 Third party앱에 제공 없이 인증,인가를 할 수 있는 오픈 스탠다드 프로토콜이다.
OAuth 인증을 통해 애플리케이션 API를 유저대신에 접근할 수 있는 권한을 얻을 수 있다. OAuth가 사용되기 전에는 외부 사이트와 인증기반의 데이터를 연동할 때 인증방식의 표준이 없었기 때문에 기존의 기본인증인 아이디와 비밀번호를 사용하였는데, 이는 보안상 취약한 구조였다. 유저의 비밀번호가 노출될 가망성이 크기 때문이다. 그렇기 때문에 이 문제를 보안하기 위해 OAuth의 인증은 API를 제공하는 서버에서 진행하고, 유저가 인증되었다는 Access Token을 발급하였다. 그 발급된 Access token으로 Third party(Consumer)애플리케이션에서는 Service Provider의 API를 안전하고 쉽게 사용할 수 있게 되었다.

출처 : https://minwan1.github.io/2018/02/24/2018-02-24-OAuth/

반응형

'Web > etc.' 카테고리의 다른 글

신용카드 번호 체계(BIN)와 검증번호  (0) 2020.06.02
[OS및 브라우저별 userAgent값]  (1) 2020.04.06

+ Recent posts