Original blog, reproduced please indicate the source
Blog.csdn.net/hello_hwc
The company may be working for a long time, so that iOS are accustomed to write iOS, since the last article in a classmate raised, I will be changed. This article describes the server certification process, I have little knowledge of the server side, so if there is inaccurate place, please correct me, I will promptly make changes.
Certifications and authorizations
Simply put, the server has a lot of resources stored, these resources are not accessible to clients, the client to access resources, the first time to let the server know that these resources I can access, this is a process of authentication and authorization.
Authentication mode for private platforms (servers for use by their own apps) static user name password
Note: The specifics are related to the server-side design, not all of them.
- App username password login, and then send the user name password to the server, password generally do encryption processing.
- The server decrypts the password and then authenticates, after the authentication succeeds, returns the ID of a session and the token,session has an expiration date
- When the app makes API requests, it sends the SessionID to the server, and after the session expires, the app automatically uses tokens to get a new session.
Dynamic password
The most common is the dynamic password that is launched into the phone.
BTY:
Verification Code
When the server discovers the client login exception, it sends an image as the verification code to the app.
Open platform (for third-party application access) authentication method
There are two common ways of
Http Basic Authorization
Simply put, each API request needs to include the user name password, the user name password as the HTTP header line.
iOS code is also relatively simple
Note that the following code only adds an authoritative header, and if you want to use it normally, you usually need a different header.
NSString *username = @""; NSString *password = @""; nil; NSString *basicAuthStr = [NSString stringWithFormat:@"%@:%@",username,password]; NSData * basicAuthData = [basicAuthStr dataUsingEncoding:NSASCIIStringEncoding]; NSString * basicAuthValue = [NSString stringWithFormat:@"Basic %@",[basicAuthData base64EncodedDataWithOptions:0]]; [request setValue:basicAuthValue forHTTPHeaderField:@"Authorization"];
OAuth 2
Mainly consists of four parts
- RO (Resource Onwer) resource owner, the person who has the ability to authorize resources.
- RS (Resource Sever) resource server, the device that actually stores the resources
- Client third-party application, after the RO authorization, you can access the corresponding resources
- As (authorization server) authorizes the server to authenticate visitors, provide RO with an authorization approval process, and ultimately issue access tokens to visitors. Access token is effective.
The approximate process is this.
- Client requests resource owner to access ro some resources
- RO returns some temporary tokens to the client, allowing the client to authorize through as
- The client is authorized by the things RO returns to AS
- Return acccess Token to client after successful as authorization
- Third-party apps take access token to the server
- The server verifies that access Token, if it has not been forged, does not expire, returns the resource to Cilent, or performs the related action.
An example of OAuth 2 on Sina Weibo
Third-party applications to access Sina Weibo as an example
- App provides app key (app unique logo) and app Secret (app key) to the ro of Weibo, which can be applied on Weibo in advance
- Microblogging RO to verify app identity, provide ro a temporary oauth_token (authorization token)
- App is licensed on a temporary oauth_token to an as license (local Weibo app or WebView)
- The user enters the user name password and agrees to authorize, and as returns to access Token
- The app takes access tokens for HTTP operations, such as sharing tweets.
IOS Network Development (v) Some basic understanding of authentication and authorization