지밍이 블로그

1. 인벤토리선택 > 구성 > 스토리지 > 데이터스토어에 마우스 우클릭 > 데이터 브라우저
2. 새폴더 만들어서 복사할 vm폴더의 아래의 3개 파일을 복사해 넣는다.
.vmdk --> 스냅샷 마지막버전 파일
.vmx
,xmxf
3. 복사가 완료되면, 복사된 .vmx파일 우클릭 > 인벤토리에 추가 (생성할 vm이름을 알맞게 수정)
4. 만들어진 vm을 실행
5. "복사함" 선택 후 확인

6. 끝

<OAuth 2.0>

[개요]
- 모바일, 플랫폼의 시대가 도래하면서(Open API) 데이터는 REST&JSON 포맷을 기반으로하여 API를 제공
- 인증방식은 OAuth2.0을 사용

[OAuth 1.0a]
- OAuth 1.0 : 트위터를 비롯한 웹 개발자들이 API인증 및 로그인한 사용자에 대한 권한부여를 동시에 제공하도록 하는 인증 프로토콜
- 2007년 10월 OAuth1.0 출시(보안결함)
- 2009년 OAuth 1.0a 발표 (정식 "The OAuth 1.0 Protcol")

- 장점
  a. API 인증 시 써드파티 어플리케이션에게 사용자의 비밀번호를 노출하지 않고 인증가능
  b. 인증과 API권한부여를 동시에 할 수 있음

- 동작방식
 : user / consumer / service provider

                                   <OAuth 1.0a 트라이앵글>

  : 3-legged OAuth라고도 함
  a. user : 트위터사용자
  b. consumer : 트위터 단말 어플리캐이션
  c. service provider : 트위터 API 서비스

  #가설 ?
    새로운 어플을 다운받았으나, 신뢰할 수 없다. (어떤짓을 할지 몰라~)
    이때 인증토큰을 사용하여 인증을 하게됨

[인증토큰]
- 인증이 완료되면 컨슈머(예, PocketTube)는 인증 토큰을 받게된다.
- 특징
   a. 컨슈머가 사용자의 id/pw를 가지지않고 API를 사용할 수 있음
   b. 필요한 API에만 제한적으로 접근할 수 있도록 권한제어가 가능
   c. 사용자가 서비스 프로바이더(예, YouTube)의 관리페이지에서 권한 취소가 가능
   d. 패스워드 변경 시에도 인증 토큰은 계속 유효함

   (※ c번의 유용한 점? 사용자가 핸드폰을 잃어버렸을때, 서비스프로바이더의 관리페이지에서 어플리케이션 인증을 취소할수 있다.)


[OAuth 2.0]
* OAuth 1.0a와 호환이 않되고 사용되는 언어부터 시작해 많은 것들이 다름

- 거의 초기부터 IETF 표준 프로세스 안에서 만들어지고 있음.
- 2010년 4월부터 등록됨
- 모바일에서의 OAuth1.0a의 불편함, signature 생성의 복잡함, 과한 CPU 소비, 기능과 규모의 확장성을 지원하기 위해 만들어짐
- 정식명칭 "OAuth 인증 프레임워크" ("The OAuth 2.0 Authorization Framework")

- 개선사항
  a. 사용함에 있어서 간단해짐
  b. 더 많은 인증방법을 지원(웹브라우저, 모바일 등 다양한 시나리오에 대응이 가능)
  c. 대형 서비스로의 확장성 지원

- 용어
  a. Resource Owner : 사용자
  b. Resource Server : API 서버
  c. Authorization Server : 인증서버(API와 같을 수도 있음)
  d. Client : 써드파티 어플리케이션

[대표적 서비스 프로바이더]

[OAuth 2.0 인증방식]
- 3-legged를 비롯하여 2-legged등 다양한 인증 방식 지원
- but, 기본은 3-legged

  a. Authorization Code Grant
   - 웹 서버에서 API를 호출하는 등의 시나리오에서 Confidential Client가 사용하는 방식
   - 로그인시 페이지 url에 response_type=code라고 넘김

  b. Implicit Grant
   - 브라우저 기반의 어플리케이션이나 모바일 어플리케이션에서 사용하는 방식
   - Client 증명서를 사용할 필요가없고, 실제로 가장 많이 사용하는 방식
   - 로그인시 페이지 url에 response_type=token이라고 넘김

  c. Password Credentials Grant
   - 2-legged방식
   - Client에 id/pw를 저장해놓고 id/pw로 직접 access token을 받아오는 방식
   - client를 믿을 수 없을때에는 사용하기에 위험이 있음
   - 로그인시 API에 POST로 grant_type=password라고 넘김

  d. Client Credentials Grant
   - 어플리케이션이 Confidential client일때 id와 secret을 가지고 인증하는 방식
   - 로그인시 API에 POST로 grant_type=client_credentials라고 넘김

  e. Extension
   - 추가적인 인증방식을 적용할 수 있도록 함

[다양한 토큰 지원]
  - 기본적으로는 Bearer토큰, 즉 암호화하지 않은 그냥 토큰(HTTPS를 사용하여 HTTPS의 암호화에 의존)
  - 다른 토큰 방식도 지원하지만 거의 안씀

  - "Refresh Token"
   : 같은 access token을 오래 사용시, 노출 위험이 있으므로 refresh token개념을 도입
   : 만료기간을 짧게하고 refresh token으로 access token을 갱신