IOS network development (5) basic understanding of authentication and authorization, and ios authorization
Original Blog, reprinted, please indicate the source
Blog.csdn.net/hello_hwc
I have been working in the company for a long time, so that iOS is habitually written as IOS. Now that a classmate mentioned in the previous article, I will change it. This article introduces the process of server authentication. I know little about the server. If there is any inaccuracy, please correct me and I will modify it in time.
Authentication and authorization
Simply put, many resources are stored on the server. These resources are not accessible by the client. When the client wants to access resources, let the server know that these resources can be accessed by me, this is a process of authentication and authorization.
Static username and password authentication for private platforms (servers for your apps)
Note: The specific situation is related to the server design. Not all of them are like this.
Dynamic Password
It is common to use dynamic passwords on mobile phones.
BTY:
Verification Code
When the server detects a client logon exception, it sends an image to the App as the verification code.
Open Platform (for third-party application access) authentication method
Two common methods
Http Basic Authorization
To put it simply, each API request requires a line containing the user name and password and the user name and password as the http header.
IOS code is also relatively simple
Note that the following code only adds an authorized Header. If you want to use it normally, other headers are usually required.
NSString *username = @""; NSString *password = @""; NSMutableURLRequest * request = 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
It consists of four parts:
- Resource owner of RO (resource onwer), who authorizes resources.
- RS (resource sever) resource server, the device that actually stores Resources
- Client third-party applications can access the corresponding resources after RO authorization
- AS (authorization server) authorizes the server to authenticate the visitor, provide the authorization approval process for RO, and finally issue an Access Token to the visitor. The Access Token is valid.
The general process is like this.
Take Sina Weibo's OAuth 2 as an Example
Third-party applications want to access Sina Weibo as an Example