Resource Server: 사용자의 정보를 가져올 Server를 의미한다. gihub, facebook, google 등이 될 수 있다.
Client ID: 클라이언트를 식별할 수 있는 아이디이다.
Client Secret : 클라아인트 비밀번호이다. 절대로 외부에 노출되면 안되는 정보이다.
Authorized redirect URLs : Resrouce Server가 권한을 부여하는 과정에서 Authorized Code를 전달해 주는데 전달할 주소이다.
등록
OAuth를 제공하는 Resource Server 에서 프로젝트를 만들어서 Client ID, Client Secret, Authrozied redirect URLs 설정한다.
클라이언트에서 환경 변수 등으로 Client ID, Client Secret 을 저장한다.
Resource Owner 승인
Resource Server를 통해 로그인할 수 있는 화면을 구성하거나 API를 구현한다.
Resource Server로 요청을 보내면 되는데, [https://resource.server/?client_id=1&scope=<기능들>&&redirect_uir=<RedirectURI>](https://resource.server/?client_id=1&scope=<기능들>&&redirect_uir=<RedirectURI>) 이런 형태의 요청을 보내면 된다.
Resource Server 에서 요청을 받으면 client_id 를 확인하고 등록된 아이디가 있다면 요청받은 redirect URL 과 등록된 redirect URL 이 맞는지 확인한다. 여기서 틀리면 종료된다.
그다음, 요청한 기능에 대한 허용 할 것인지에 화면을 Resource Server에서 보여준다.
Resource Owner 가 승인하면 Resource Server에 승인 했다는 정보를 전달하고 Server는 Owner에 id 와 기능 scope 를 저장한다.
Resource Server 승인
Server 는 authorization code 를 담아서 Owner 에게 전달한다. 이때 헤더에 Location을 추가해서 응답할때에는 Client로 리다이렉트 할 수 있도록 한다. Location: [https://client/callback?code=3](https://client/callback?code=3)
Client 는 콜백 주소를 통해서 authorization code 를 알 수 있게 된다.
Client 는 Resouce Server에게 직접 token을 요청하게 된다. 이때, authorization code, client_id, client_scret, redirect_uri 를 전달한다.
Server는 정보를 모아서 client 와 user를 식별해서 access Token 을 발급및 응답한다.
API 사용
요청을 보낼때 Authorization: Bearer 설정하여 보낸다.
refresh token
리프레쉬 토큰을 이용해서 토큰이 만료 되었을때 다시 받아올 수 있다.
Resource Server 와 별개로 Authorization Server 를 두어서 Access Token과 Refresh Token 을 Client 에게 전달한다.
클라이언트는 Access Token을 이용해서 Resource Server에 자원을 흭득한다.
Access Token이 만료되게 되면 Resource Server로 부터 Invalid Token Error를 받게된다.
Client는 이때 Authorization Server로 부터 받은 Refresh Token을 이용해서 Access Token 을 요청하고 다시 받아온다. 처음부터 리소스 허가 요청 하는 과정을 생략할 수 있다.
인증이란? : you are who you say you are, 다양한 방법으로 인증 가능하다 통상적으로 password, id 로
먼저 회원가입을 진행해서 서버에 id, passwrod 를 저장한다.
클라이언트는 로그인 할때 회원가입한 id, password를 서버에 전송한다.
어떻게 로그인 상태를 유지할 수 있을까?
세션과 쿠기 (서버에서 사용할 수 있는 전통적인 옵션- 어떻게 로그인 상태를 유지할지에 대한 방법)
세션
서버에서 확인후 세션을 만든다 (userId, sessiontId, expiration) - Session DB에 저장 or 파일시스템이나 메모리도 될 수 있음
쿠키에 HTTP Only로 sessiontId 정보를 전달함.
다음 요청때마다 쿠키 정보를 전달해줌
장점 : 브라우저에 전달만 하면 되서 간단하고, sessionId 만 전달하면되서 사용자의 정보를 전달하지 않아도 된다. HTTP Only를 사용하면 스크립트로 못읽기 때문에 보안상의 이점도 있다.
단점 : Stateful 하기 때문에 다양한 서버들이 SettionDb를 읽어야 하고 많은 요청이 들어오게 된다. 내부적으로 네트워킹이 많아짐. 성능 하락
JWT (Json Web Token)
다음과 같은 정보를 JSON으로 만들고 토큰화해서 보낸다. header, payload, signature, 모든 정보는 인코딩해서 보내고 서버에서 secrete으로 사용하는 키도 인코딩해서 signature에 포함해서 보낸다.
로그인 하면, 로그인 정보 + 만료 시간 등등 합쳐서 JWT를 만듦.
클라이언트는 Header를 이용하여 모든 request마다 JWT를 포함해서 전달해 줌.
서버는 JWT를 검증한 후에 데이터를 반환함.
장점 : 서버에 State가 없다. 서버를 확장하거나 분산하기에 용이하다.
단점 : JWT 자체가 단점이 될 수 있다. → 계속 JWT를 주고 받아야 한다. 만약 영원히 만료되지 않은 JWT를 헤커가 탈취한다면.. 사용할때 보안에 신경써야 한다.
bcrypt 란? : 사용자 정보를 그대로 저장하는 것이 아니라 암호화 해서 저장하기 위해 사용함. → 암호화만 가능한데 (암호화 한것을 비교하는 것), salt 가 없다면 경우의 수로 암호화 해 보면서 유추할 수 있어서 salt를 포함하여 경우의 수를 늘림. 10~12 정도로 설정. 길어지면 cpu 부하 심해짐..
JWT, 32 시크릿 키로 권고 됨. 한번 발행된 토근은 변경되면 안된다. → 만약 한버이라도 변경 한다면 최종적으로 붙은 signature도 변경되어서 verify시 오류 발생하고 누군가 변경한 토큰인지 확인 가능하다.
만료될 수 있도록 만들어야 한다. → option으로 전달함. {expiresIn: 2} 이런식으로 → 2초 후에 만료
sudo gem install cocoapods 을 설치하고 프로젝트 파일로 이동한 후에 pod init을 실행한다.
프로젝트 파일에 Podfile 이 생기고 필요한 라이브러리를 pod 'Alamofire' 와 같은 방식으로 추가한다.
pod install 명령어를 통해 라이브러리를 섫치한다.
.xcworkspace 파일을 열어서 설치한 라이브러리를 사용한다.
기타
UITabelView 에서 Static Tabel View를 사용하면 이미 Cell에 갯수가 정해지기 때문에 Cell 을 아울랫 변수로 설정해서 값을 관리 할 수 있다.
비동기 작업을 함수 안에서 수행한다면 이스케이핑 클로저를 사용하여 함수가 반환된 후에도 실행되게 만들어야 한다. 왜냐면 함수가 반환되는 시점과 서버에서 응답을 받아오는 시점이 다르기 때문이다. 따라서 정의하는 클로저 앞에 @escaping 을 붙혀서 이스케이핑 클로저로 선언한다.
Alamofire 는 URLSession 과 달리 UI 쓰레드에서 동작하기 때문에 따로 DispatchQueue 를 안만들어도 된다.