OAuth1.0a spec 한글

http://oauth.net/core/1.0a/

필요한 부분만 발췌 해설(번역이 아닌것은 개인적인 해석이 들어갔기 때문)
다음에서 한글 문서를 제공했었는데 지네 서비스 2.0으로 올려다고 문서를 빼버려서 따로 정리.
OAuth1과 OAuth2의 뼈인간은 이름이 다르다.

3. Definitions용어 정의

  • Service Provider : 이름그대로 OAuth10a 인증을 제공하는 서비스 – Facebook, Twitter, Google, Daum, Naver 등이 Service Provider의 역할을 한다. 이 문서를 보는 사람들도 이 Service Provider에 접근하기 위해 OAuth를 찾고 있을겠지?
  • Consumer : OAuth10a인증을 통해 Service Provider에 접근하기를 원하는 웹사이트,앱 등
  • User : 말 그대로 일반 사용자… Service Provider에 가입하고 Consumer를 통해서 Service Provider에 접근하는 사람들
  • Protected Resource(s) : Service Provider에서 관리하는 리소스… Service Provider에서는 User의 권한에 따라 Protected Resources의 공개 여부를 결정한다
  • Consumer Developer : Consumer를 만드는 사람들
  • Consumer Key : Consumer의 로그인 ID같은 역할
  • Consumer Secret : Consumer의 로그인 비밀번호 역할
  • Request Token : Consumer에서 Service Provider에 근해 Request Token-Token Secret을 수신한다
  • Access Token : Request Token을 http://facebook.com?oauth_token?{request_token} 처럼 브라우저의 주소로 사용자를 넘겨준다. 사용자가 Service Provider에 로그인 후 사용허가를 해 주면 Service Provider에서 Consumer쪽으로 verifier값을 전달해주고 Request Token과 verifier을 이용해 ServiceProvider에서 AcceccToken과 AccessTokenSecret을 받을 수 있다. Access Token은 임시 사용자 ID와 비밀번호 역할을 하는 값으로 Access Token값이 만료되기 전까지 계속 사용 가능하다. 보통은 시간제한이 없다
  • Token Secret : Request Token, Access Token의 비밀번호..
  • OAuth Protocol Parameters : OAuth프로토콜 파라미터는 “oauth_”로 시작한다

4. Documentation and Registration
?????
OAuth includes a Consumer Key and matching Consumer Secret that together authenticate the Consumer (as opposed to the User) to the Service Provider. Consumer-specific identification allows the Service Provider to vary access levels to Consumers (such as un-throttled access to resources).

Service Providers SHOULD NOT rely on the Consumer Secret as a method to verify the Consumer identity, unless the Consumer Secret is known to be inaccessible to anyone other than the Consumer and the Service Provider. The Consumer Secret MAY be an empty string (for example when no Consumer verification is needed, or when verification is achieved through other means such as RSA).

4.1. Request URLs
Request Token URL :
User Authorization URL :
Access Token URL :

Spring과 관련 라이브러리 비교 – 스프링시큐리티 구조상의 문제점?

스프링 시큐리티는 잘 만들어진 보안 프레임워크이긴한데…

스프링을 A등급이라고하면 시큐리티는  B등급 이상으로 점수를 주긴 싫다. 스프링 소셜은 C등급?

개념적인 부분에서는 좋을지 몰라도 사용자 입장에서는 아쉬운 부분이 많이 보인다. 구조가 직관적으로 이해하기 힘들기도 하고…

 

<http>를 이용해서 설정을 쉽게 해 주는것도 좋지만 이로 인해서 구조 파악과 커스터마이징이 더 힘들어진다.

기본 코드가 너무 데이터베이스를 활용하는데에만 치중되어 있고 구현이 되어 있는 부분이 많다. 인터페이스나 구조정도만 제공되어야 할 것 같은 부분에 데이터베이스를 사용하는 구현체들이 박혀있어서 이를 대체하기가 힘들다. 특히 <http>를 사용하는 경우에는 자동화가 진행 돼 버려서 더 불편해진다.

아니면 내가 제대로 파악하지 못한걸지도…?

어쨌든 이런 부분들 일부를 수정해서 만들어볼 계획.