3. Identity and Access Management

유다시티 fullstack 수업 study note입니다

 

Authentication methods

-username and password

-single sign on (SSO)

-Multi-factor authentication (ex)) 패스워드 입력후 text massage, 보안키)

-Passwordless (password가 아예없고 text massage나 보안키 등등)

-Biometric authentication

-3rd party auth systems

 

Third-Party Auth Systems

-보통 하나의 front end에 여러 micro service(server)가 연결되어 있는 경우가 많다

- 각각의 server 마다 auth sys를 유지하는 것은 관리도 힘들고, 수정도 어렵다.

- 이럴때 auth0같은 third party sys를 사용하면 이용이 수월하고, 전문적으로 security만 하는 사이트기에 안전하다.

 

 

Auth0 사용법

FLASK 에는 regular web app이 좋음 (4개 type이 다 비슷하나, 초이스별로 tip이 좀 다름)

Callback Url이나 token expiration time 등등 setting

App을 만든 후에는 api를 만들어 줘야한다.

 

Authentication 메뉴에 보면 social media를 이용한 SSO나 passwordless 옵션도 있음.

 

auth0.com/docs/api/authentication#authorize-application

Auth0 Docs

위의 doc을 읽어보면

log-in 과 sign up 페이지 주소는

'''

https://{{YOUR_DOMAIN}}/authorize?audience={{API_IDENTIFIER}}&response_type=token&client_id={{YOUR_CLIENT_ID}}&redirect_uri={{YOUR_CALLBACK_URI}}

'''

 

audience 항목을 제외하곤 app 관련 parameter이다.

audience항목은 required 항목은 아니지만, 특정 api는 유저 permission과 role 등을 설정할 수 있다.

audience 항목의 api를 이용하여 access token을 구성하는듯.

(app과 api관계에 관해서는 auth0를 더 이용한다면 더 doc을 더 읽어볼 것)

 

해당 페이지에서 sign up을 하면, 유저탭에 해당 아이디가 있는 것을 확인할 수 있는데

해당 유저의 authorized application 항목을 확인하면 해당 app과 api가 설정되어있다.

(유저 데이터는 특정 app에 귀속되고, api까지 활용하면 role이나 permission까지 활용할수 있는듯)

 

 

Json Web Tokens (JWT)

jumbled up strings (base64 encoding)

아래의 사이트에서 디코딩가능

jwt.io/

 

header = algo, type, etc

payload = information

signature = function(header, payload, secret)

 

Symmetric authorizaition

나도 상대방도 둘다 private key를 가지고 있어야 한다.

encrypt를 하든 decrypt를 하든 아니면 signature verification을 하든지.

 

***Asymmetric algorithms***

public key만 가지고도 signature verification이 가능.

알고리즘 자체는 symmetric보다 느리기 때문에 방대한 데이터를 encrypt하기에 좋진 않다.

하지만 signature verification의 경우 private key를 공유하지 않아도 된다는 보안상의 장점이 있다.

예) encrypt는 퍼블릭키 프라이빗키 둘다 할수 있지만, decrypt는 프라이빗키만 가능.

예) 시그니쳐의 경우 프라이빗키만 시그니쳐를 만들수 있지만 verification은 퍼블릭으로만으로도 가능.

(내가 구현한 auth0가 이것)

퍼블릭키와 프라이빗키가 pair로 만들어진다.

 

 

Storing Tokens in Web Browsers

- Local storage

브라우저 안에서 자바스크립트를 이용, 스트링을 딕셔너리 형태로 저장하는 방법

domain specific (특정 호스트만 공유 가능, 여러탭이 열러있는 경우 유다시티 호스트면 접근 가능하지만, 구글.com 탭은 불가)

 

jwt = response.jwt
localStorage.setItem("token", jwt)

jwt = localStorage.getItem("token")

 

해커가 브라우저 자바스크립트에 접근하게 될 경우 해킹의 위험이 있다.

user input 창이 있는 경우에, Input sanitation (escape) 를 반드시 해야함.

 

Sending Tokens, Recieving and Verifying

authorization 을 위한 token은 보통 bearer라는 keyword가 prepend되어 있다.

 

bearer (token)

 

flask 같은 경우에는 request.headers['Authorization'] 을 이용하여 리퀘스트에서 해당 토큰을 확인할 수 있다.

포스트맨 등을 통해 실제 리퀘스트를 보내고 받아 보는 연습 해보기. (강의 동영상 참고)

auth측 code를 보면 asymmetric authorization이 어떻게 실제로 이뤄지는지 확인할 수 있다.

(public키를 확인하고 decode 및 verification)

 

 

**python decorator와 function tools wrap에 대한 이해

데코레이터가 여러 layer인 경우에 정확히 어떤 데코에 function이 parameter로 들어가는지 정해주기 위해

wrap이 필요하다(내생각)

**검색해보면 관련 docs가 많다 

 

Plain Text, Sql injection, Brutal force attack

sql injection 과 같은 공격을 막기 위해서 plain text input은 항상 sanitizing 하고

가급적 ORM을 이용하거나, prepared sql statements 이용하는 것이 좋다(규격화 시켜서, 규격외의 sql은 무시하도록)

 

brutal force attack은 login attempt 숫자 제한으로 막을 수 있다.

 

 

serializaiton and logging (console.log)

serializaiton은 data를 shared format으로 바꾸는 일을 말하는데, (보통 json object)

주요 정보는 serilization에서 제외해야 한다.

 

디버그나 개발을 위해서 server에서 일어나는 일을 log하는 경우에도, 프로덕션에 들어가면 꼭 없앨 것.

 

 

Hashing, rainbow tables, Salt

Hash is a function that produces a unique message digest.

hash는 decrypt기능이 없다.

 

auth0에서 연습한 rs256 의 경우 asymettric hashing 이라 할수 있음.

 

rainbow table이라는 table로 해당 알고리즘으로 자주 등장하는 단어를 매우 많이 hash해서

hash값 별로 original data를 역추적하는 해볼수 있다.

 

hashing 전에 original data에 salt라는 특정 단어를 합치는 방법이 있는데,

salt값을 비밀로 유지할수 있다면, rainbow table를 이용한 해킹에서 안전할수 있다.

 

 

Role-permission based access (Auth0)

payload에 permission 관련한 access 내용을 넣는것.

 

in Api setting screen, create new permissions within the permission tab

navigate to role screen and define a new role

assign your newly created api permissions to the role

in api setting screen, turn on enable RBAC and 'add permission in the access token' settings

assign the role to a user in your auth system

login through your hosted login screen and decode the token using jwt.io

 

 

Restricting Features in Frontend

아래와 같은 자바스크립트로 frontend에서 직접 token을 읽을 수 있다.

function parseJwt (token) {
    // https://stackoverflow.com/questions/38552003/how-to-decode-jwt-token-in-javascript
   var base64Url = token.split('.')[1];
   var base64 = decodeURIComponent(atob(base64Url).split('').map((c)=>{
       return '%' + ('00' + c.charCodeAt(0).toString(16)).slice(-2);
   }).join(''));

   return JSON.parse(base64);
};

frontend에서 permission token을 직접 읽는게 보안상은 좋지 않지만,

권한과 관련없는 항목은 ui에서 아예 지워버리는 등 user experience에 기여할 수 있다.

 

validation은 backend에서 하는것이 좋다.

 

 

Thinking Adversarially

using git

- small feature branch, stage branch, master branch

로 나누어 단계별로 변경 사항을 적용하는 것이 좋다.

직급별로 시니어가 아래단계에서 올라오는 머징 리퀘스트를 컨펌하기 전에 코드리뷰 해주는 방식이 필요

(깃헙에 권한 부여 및 코드변경 리뷰 기능이 있다)

 

TDD

-unittest 나 postman의 test 기능을 이용해서 테스팅을 해가며 개발하는것이 안전

 

-phishing이나 social engineering(소셜미디어에 공개된 정보를 활용하는 해킹)을 알고 조심할것

 

-reading recent news, OWASP TOP 10, Subscribing to vulnerability monitoring(깃헙에서 whitesource라는 회사와 파트너해서 우리가 쓰고 있는 디펜던시에 vernerability가 발견되면 알려줌)