한국어

Coding

온누리070 플레이스토어 다운로드
    acrobits softphone
     온누리 070 카카오 프러스 친구추가온누리 070 카카오 프러스 친구추가친추
     카카오톡 채팅 상담 카카오톡 채팅 상담카톡
    
     라인상담
     라인으로 공유

     페북공유

   ◎위챗 : speedseoul


  
     PAYPAL
     
     PRICE
     

pixel.gif

    before pay call 0088 from app


https://blog.restcase.com/restful-api-authentication-basics/


Almost every REST API must have some sort of authentication. One of the most common headers is call Authorization. Wait a minute, we are talking about authentication but why the Authorization header?

Authentication vs. Authorization

The distinction between authentication and authorization is important in understanding how RESTful APIs are working and why connection attempts are either accepted or denied:

  • Authentication is the verification of the credentials of the connection attempt. This process consists of sending the credentials from the remote access client to the remote access server in an either plaintext or encrypted form by using an authentication protocol.

  • Authorization is the verification that the connection attempt is allowed. Authorization occurs after successful authentication.

In other words: Authentication is stating that you are who are you are and Authorization is asking if you have access to a certain resource.

I know that it is a bit confusing that in REST APIs we are using the Authorization header for doing Authentication (or both) but if we remember that when calling an API we are requesting an access to certain resource it means that the server should know whether it should give access to that resource or not, hence when developing and designing RESTful APIAuthorization header sounds just fine.

Basic Authentication

The most simple way to deal with authentication is to use HTTP basic authentication. We use a special HTTP header where we add 'username:password' encoded in base64.

GET / HTTP/1.1
Host: example.org
Authorization: Basic Zm9vOmJhcg==

Note that even though your credentials are encoded, they are not encrypted! It is very easy to retrieve the username and password from a basic authentication. Do not use this authentication scheme on plain HTTP, but only through SSL/TLS.

HTTP Basic Authentication

HMAC

One of the downsides of basic authentication is that we need to send over the password on every request. Also, it does not safeguard against tampering of headers or body.

Another way is to use HMAC (hash based message authentication). Instead of having passwords that need to be sent over, we actually send a hashed version of the password, together with more information. Let's assume we have the following credentials: username "username", password "secret".

Suppose we try to access a protected resource:

/users/username/account

First, we need to fetch all the information we need, and concatenate this.

GET+/users/username/account

Here, we just concatenate the HTTP verb and the actual URL. We could add other information as well, like the current timestamp, a random number, or the md5 of the message body in order to prevent tampering of the body, or prevent replay attacks. Next, we generate a hmac:

digest = base64encode(hmac("sha256", "secret",     "GET+/users/username/account"))

This digest we can send over as a HTTP header:

GET /users/username/account HTTP/1.1
Host: example.org
Authentication: hmac username:[digest]

Right now, the server knows the user "username" tries to access the resource. The server can generate the digest as well, since it has all information.

Please note that the "password" is not encrypted on the server, as the server needs to know the actual value. This is why te name "secret" is preffered and not a "password".

Even if a hacker was listening in on the conversation, they could not use the authentication information to POST data to user's account details, or look at some other users accounts, or any other URL, as this would change the digest and the hacker does not have the secret that both the server and client has.

However, the hacker could access user's account whenever it wants since it doesn't change the digest. This is why many times more information is send over, like the current time, and a nonce:

digest = base64encode(hmac("sha256", "secret", "GET+/users/username/account+20apr201312:59:24+123456"))

We added two extra pieces of information. The current date and a number that we only use once (nonce)

GET /users/username/account HTTP/1.1
Host: example.org
Authentication: hmac username:123456:[digest]
Date: 20 apr 2013 12:59:24

The server can reconstruct the digest again, since the client sends over the nonce and date. When the date is not in a certain range of the current servers time (say, 10 minutes), the server can ignore the message, as it probably is a replay of an earlier send message (note: either that, or the server or clients time is wrong. This is a common issue when dealing with time-limited authentications!).

The nonce is a number we only use once. If we want to access the same resource again, we MUST change this number. This means that every time we access a resource, the nonce will be different, and thus the digest will be different, even if we access the resource in the same second. This way we are sure that no replay attacks can be done. Each request is only valid once, and only once.

OAuth 2.0 or OAuth 1.0

OAuth 2.0 or OAuth 1.0

A Little History

In December 2007, OAuth 1.0 addressed delegation with a framework based on digital signatures. It was secure and it was strong. Major players began to adopt it. Google began OAuth 1.0 support in 2008. By 2010, Twitter forced all third-party apps to use their OAuth 1.0 implementation.

However, OAuth 1.0 required crypto-implementation and crypto-interoperability. While secure, it was a challenge for many developers to implement.

Then came OAuth 2.0 in October 2012.

Building a secure OAuth solution is no easy challenge. Large enterprises joined the OAuth standard body and influenced it in many ways. While OAuth 2.0 is much easier to implement than OAuth 1.0 with its crypto underpinnings, the new version contains many compromises at the security level.

However, support for non-browser implementations and a clear separation of resource delivery and authorization helped make the new standard more usable for large enterprises and more.

In many cases, it is no longer feasible to use OAuth 1.0 as a client-side implementer. For example, Google moved away from OAuth 1.0 in April 2012, and no longer permits the use of OAuth 1.0. However, Twitter still fully supports OAuth 1.0. (for more information - https://dev.twitter.com/oauth)

It is very rare to see new authorization server implementations of OAuth 1.0. However, you can still consider OAuth 1.0 if your resource provider still supports it (and has committed to continue supporting it), you have developers with good experience in cryptography, and you have good key management capabilities.

These are a lot of “ifs,” and OAuth 2.0 is almost always the right choice today. If your desire is to use OAuth with proper cryptography, the trend is more and more to use OAuth 2.0 with cryptographic extensions. If you are designing and developing a new API, OAuth 2.0 is your choice!

Still wondering what to do? Compare the security properties of both versions and decide which is right for your implementation.

OAuth Way Of Work

OAuth 1.0
  • Transport-Independent: Security is not delegated to HTTPS/TLS.
  • Founded in cryptography, especially digital signatures : Digital signatures are used to prove the integrity and authenticity of a message. Digital signatures can ensure that a certain message was sent from a specific source and that the message and signature were not tampered with in any way. A signed message is tied to its origin. It cannot be tampered with or copied to another source, but client-side implementations can be especially complex.
  • Messages are each individually cryptographically signed : If a single message within the communication is constructed or signed improperly, the entire transaction will be invalidated
  • Basic Signature Workflow.
Example workflow:
  1. Client application registers with provider, such as Twitter.
  2. Twitter provides client with a “consumer secret” unique to that application.
  3. Client app signs all OAuth requests to Twitter with its unique “consumer secret.”
  4. If any of the OAuth request is malformed, missing data, or signed improperly, the request will be rejected.

Note: Some use the OAuth 1.0 scope parameter to carry authorization/entitlement in addition to the token; that can be a useful architecture consideration.

OAuth 2.0
  • Transport-Dependent : Most security defenses are delegated to HTTPS/TLS. A typo, an improper TLS configuration, a failure to properly validate a certificate, or vulnerabilities in an underlying library can lead to a man-in-the-middle (MiTM) attack, compromising all OAuth communications.
  • Centered around bearer tokens : These are easy for integration but not great for security. Bearer tokens do not provide internal security mechanisms. They can be copied or stolen but are easier to implement.
  • Easier : OAuth 2.0 is much more usable, but much more difficult to build securely.
  • Flexible : OAuth 1.0 only handled web workflows, but OAuth 2.0 considers non-web clients as well.
  • Better separation of duties : Handling resource requests and handling user authorization can be decoupled in OAuth 2.0.
  • Basic Signature Workflow.
Example workflow:
  1. Client application registers with provider, such as Twitter.
  2. Twitter provides client with a “client secret” unique to that application.
  3. Client application includes “client secret” with every request.
  4. If any of the OAuth request is malformed, missing data, or contains the wrong secret, the request will be rejected.
See also:
Summary

Please keep in mind that Basic authentication and OAuth versions MUST be protected through SSL/TLS. They should not be used over plain HTTP.

Authentication is stating that you are who are you are and Authorization is asking if you have access to a certain resource. When working with REST APIs you must remember to consider security from the start.

RESTful API often use GET (read), POST (create), PUT (replace/update) and DELETE (to delete a record). Not all of these are valid choices for every single resource collection, user, or action. Make sure the incoming HTTP method is valid for the session token/API key and associated resource collection, action, and record.

For example, if you have an RESTful API for a library, it's not okay to allow anonymous users to DELETE book catalog entries, but it's fine for them to GET a book catalog entry. On the other hand, for the librarian, both of these are valid uses.

번호
제목
글쓴이
63 [SSL]HTTPS통신을 위한 SSL인증서 발급하기(OpenSSL) 원리까지 충실하게 설명잘됨
admin
2020-02-13 7836
62 인증 기관에서 발급한 SSL 인증서 설치 및 사용설명
admin
2020-02-13 3448
61 iOS NSURLSession Example (HTTP GET, POST, Background Downlads )
admin
2019-06-04 5512
60 iOS Tutorial - Part 26 - HttpRequest POST, GET (NSURLConnection)1
admin
2019-05-20 4328
59 Simple http post example in Objective-C?
admin
2019-05-20 3881
58 리눅스 CentOS 6.5 SSL 구축 방법
admin
2018-06-01 5953
57 무료 SSL 인증서 SSL For Free
admin
2018-05-26 5981
56 도메인클럽 m 또는 www등의 서브도메인(a레코드) 추가는 어디서 할 수 있나요?
admin
2018-05-25 5035
55 Certificate Installation : Node.js in Linux
admin
2018-05-25 4459
54 online-csr-and-key-generator CSR 온라인 제너레이터 생성 만들기 Private key
admin
2018-05-25 4616
53 COMODO SSL www.gogetssl.com namecheap.com SSL 인증서 구매 서버에 적용 순서
admin
2018-05-25 6564
52 인증서 취소 How to cancel an SSL certificate? www.namecheap.com
admin
2018-05-25 4843
51 Android SSL 프로그램 공인인증서 사설 인증서 ROOTCA Self-signed 인증서 에러 원인
admin
2018-05-25 5236
50 Retrofit is one of the most popular HTTP Client Library for Android 간결하고 요점정리
admin
2018-05-23 5345
49 SSL 프로그래밍 참고
admin
2018-05-23 4622
48 HTTPS 및 SSL을 사용한 보안 구글 문서
admin
2018-05-23 7955
47 Consuming APIs with Retrofit
admin
2018-05-22 5332
46 COMODO SSL Analyzer ip 도메인 모두 가능합니다
admin
2018-05-22 4758
45 OpenSSL 로 ROOT CA 생성 및 SSL 인증서 발급 순서 Self Signed Certificate
admin
2018-05-22 5497
44 Android에 루트 CA 설치
admin
2018-05-22 6591
43 How to update OpenSSL on Debian testing
admin
2018-05-22 5055
42 신뢰되지 않는 인증서를 사용하여 SSL 구성
admin
2018-05-22 9589
41 OpenSSL tips and common commands
admin
2018-05-22 5389
40 How to get FREE SSL Certificate for Website (HTTPS) 인증서 무료로 받기
admin
2018-05-22 4521
39 retropit
admin
2018-05-20 4678
38 SSL test code
admin
2018-05-20 5095
37 HttpsURLConnection в ASyncTask https
admin
2018-05-19 4750
36 protected String doInBackground(String... strings) {
admin
2018-05-19 4522
35 Using Google Spread sheet as DataBase Part -2
admin
2018-05-19 5056
34 Android: HTTPS (SSL) connection using HttpsURLConnection
admin
2018-05-19 5301
33 HttpsUrlConnection, you can refer to my following sample code good
admin
2018-05-19 4562
32 how to use HttpsUrlConnection instead of DefaultHttpClient
admin
2018-05-19 4611
31 Https simple get request
admin
2018-05-19 4730
30 Base64 encoded value of [API-key]:[API-Secret] appending the "Basic " string in start.
admin
2018-05-19 5852
29 Class: https.Server
admin
2018-05-19 5080
28 HTTP2 server push in depth with node.js
admin
2018-05-19 5410
27 HSTS forces the client (browser accessing your server) to direct all traffic through HTTPS
admin
2018-05-19 4709
26 https ssl node js real code
admin
2018-05-19 4969
25 https 및 openssl 키값 decoding 확인 ssl tls
admin
2018-05-19 4869
24 TLS/SSL Concepts nodejs how to
admin
2018-05-19 5242
23 HTTPS Authorized Certs with Node.js
admin
2018-05-19 5400
22 How to Use SSL/TLS with Node.js Related Topics
admin
2018-05-19 5288
21 openssl website
admin
2018-05-19 4495
20 node js HTTPS server and client
admin
2018-05-19 4716
19 RESTful API with NodeJS/Express mysql
admin
2018-05-19 4947
18 Build a Rest API for Node & Mysql 2018 JWT
admin
2018-05-19 5315
17 Using SSL with Express 4 and Node.js
admin
2018-05-19 5128
16 https node js rest api express
admin
2018-05-19 4532
15 9 FREE Useful Online SSL/TLS Certificate Tools
admin
2018-05-19 6199
14 Do you know where your app’s secrets are?
admin
2018-05-19 5243
13 node js rest with express
admin
2018-05-19 5409
12 simple HTTPS JSON REST server using node.js
admin
2018-05-19 4615
11 5 Ways to Make HTTP Requests in Node.js
admin
2018-05-19 21198
10 express() detail easy doc
admin
2018-05-19 17025
9 express https simple example
admin
2018-05-19 4445
8 Online CSR and Key Generator
admin
2018-05-19 4585
7 SSL Converter checker
admin
2018-05-19 5314
6 here is a complete working example. rest api https
admin
2018-05-19 4564
5 node-rest-client
admin
2018-05-19 5200
4 Rules for REST API URI Design
admin
2018-05-19 5590
RESTful API Authentication Basics
admin
2018-05-19 5954
2 Benefits For REST APIs with HTTP/2 HTTP/1.x vs HTTP/2
admin
2018-05-19 58974
1 HTTPS, Redis, FCM, EC2 Setup 키생성 인증서 요청서 openssl 이용 상세한설명
admin
2018-05-19 4138