OAuth 2.0 구현

Security/OAuth 2014. 1. 1. 17:58


확인 사항

implicit grant >

* client 단에서 요청 파라미터

The client includes its client identifier, requested scope, local state, and a redirection URI

- response_type REQUIRED.  

Value MUST be set to "token".

- client_id  REQUIRED.  

The client identifier as described in Section 2.2.

- redirect_uri OPTIONAL. 

As described in Section 3.1.2.

- scope OPTIONAL.  

The scope of the access request as described by Section 3.3.

- state RECOMMENDED.


The authorization server validates the request to ensure that all required parameters are present and valid. The authorization server MUST verify that the redirection URI to which it will redirect the access token matches a redirection URI registered by the client as described in Section 3.1.2.

참조 - http://tools.ietf.org/html/rfc6749#section-4.2



* as 단에서 응답 정보

HTTP Redirect 302 Found 형태로 응답한다.

- access_token REQUIRED.  

The access token issued by the authorization server - token_type REQUIRED.  

The type of the token issued as described in Section 7.1.  

Value is case insensitive. - expires_in RECOMMENDED.  

The lifetime in seconds of the access token. - scope OPTIONAL, 

if identical to the scope requested by the client; otherwise, REQUIRED. The scope of the access token as described by Section 3.3. - state REQUIRED 

if the "state" parameter was present in the client authorization request. The exact value received from the client.

The authorization server MUST NOT issue a refresh token.

참조 - http://tools.ietf.org/html/rfc6749#section-4.2



*  client단에서 redirect_uri를 어떻게 구현하며 꼭 필요한가?

The implicit grant type does not include client authentication, and relies on the presence of the resource owner and the registration of the redirection URI.

참조 - http://tools.ietf.org/html/rfc6749#section-4.2



* implicit grant에서도 refresh_token이 발급되나?

Issuing a refresh token is optional at the discretion of the

authorization server. If the authorization server issues a refresh

token, it is included when issuing an access token.

The token denotes an identifier used to retrieve 
the authorization information.

참조 - http://tools.ietf.org/html/rfc6749#section-1.5






구현 참조

http://techblog.hybris.com/2012/08/10/oauth2-server-side-implementation-using-spring-security-oauth2-module/


https://github.com/spring-projects/spring-security-oauth/blob/master/samples/oauth2/sparklr/src/main/webapp/WEB-INF/spring-servlet.xml



* javaConfig

http://spring.io/blog/2013/07/05/spring-security-java-config-preview-oauth


https://github.com/spring-projects/spring-security-javaconfig/blob/master/samples/oauth2-sparklr/src/main/java/org/springframework/security/oauth/examples/sparklr/config/OAuth2ServerConfig.java






Spring Security Oauth 2.0 Sample

https://github.com/spring-projects/spring-security-oauth/tree/master/samples/oauth2/sparklr


* flow

1. client에서 client_id, scope 등을 입력하여 /oauth/confirm_access 으로 GET 요청

2. 서버에서 client_id, scope 확인 후 /access_confirmation.jsp 파일 응답

3. 사용자가 scope를 승인/거절 여부 체크하고 client는 /oauth/authorize 으로 POST 요청

4. 서버에서 사용자 인증을 위해 /login.jsp 파일 응답

5. 사용자가 ID/PW 입력하고 client는 /login.do 으로 POST 요청

6. 서버에서 authentication-manager 설정에 의해 사용자 인증 처리 

7. 사용자 인증 처리 후 authorization-server 설정에 의해 client로 access token 발급






'Security > OAuth' 카테고리의 다른 글

OAuth 2.0 이해  (0) 2013.12.29
OAuth 1.0a 이해  (0) 2013.12.29
OAuth  (0) 2012.05.22
Posted by linuxism
,