Authorization module for the site using the Wargaming.net Public API

Since the release of the WG P API in beta testing, the most popular question has been "how to make authorization on the site."
It just so happened - man is a lazy creature.
In order to simplify the life of other participants of the Wargaming Developer Partner Program, I want to share my experience in creating an authorization module for the site.

There are two options.
1. To use OpenID
Logic of the authorization process wargaming already described, articles about OpenID on a hub
2. Using API methods to create an authorization module.
I will not describe plugins for all popular CMS - I will describe only the general scheme and give an example of code.

Theory

For user authentication, at the moment, the WG API has three methods:
auth / login - the method is used to authenticate the user - get access_token.
auth / prolongate - using this method, you can extend access_token without user intervention
auth / logout - the method for destroying access_token

access_token is used to obtain private information about the player’s account - information about the technique that is in the hangar, account identifiers of friends of the player, etc.

To obtain access_token, as mentioned above, the auth / login method is used, which sends information about the authorization status to the address specified in the redirect_uri parameter

One of the WG developers reported:

It was decided to expand the capabilities of the auth / login method and separation will be introduced (with successfully entered information):
1) User redirection will be made to one URL;
2) Authorization information will be sent to the second one (using the POST or GET method).

Let's return to the theory.

Work algorithm

Link generation for user redirection

First of all, you need to turn to the auth / login method with a request to generate a URL for further redirecting the user.
For this helmet request to , where
https://api.worldoftanks.ru/wot/auth/login/?application_id=&redirect_uri=&nofollow=1
- application_id of the application for which you need to register in the developer's office ;
- URL of the script handler;
The parameter value is nofollow = 1, so that the method returns the URL in the response body instead of a redirect.

Our auth.php will perform two tasks at once: generate a link and redirect it, or authorize if the user returns after the redirect.

Redirecting a user to the WG website

In the example, the script itself redirects the user after generating the link.
By changing a couple of lines of code, you can stir it up with javascript in order to write “Loading ...” (or paste loader.gif) after clicking on the “Login” button - it always looks beautiful.
While the user admires the inscription (well, or the picture), js will send a request to the script, he will send a request to api, api will respond to the script, the script will return the link, and finally js will redirect the user to it.
It is not possible to directly send a request to the API by the js, since WG DPP rules prohibit the application_id from being publicized.

User Return

After a player logs in to the WG website and allows our site to view its detailed statistics, it will be redirected to
? & status = ok & access_token =& nickname = <_nickname> & account_id =& expires_at =
If no errors happen ...
This way our script will get the data:
status access_token nickname account_id expires_at
But for now, this data cannot be trusted!

Verification of data received after user return

If we plan to do authorization, we must be sure that the data received is truthful and transmitted precisely from the WG website, and not manually registered.
It is precisely because of this moment that the method’s work will be redone - at the moment, we cannot know for sure whether the player, with these parameters, came from the wargaming website or typed them in the address bar.
$ _SERVER ['HTTP_REFERER'] does not provide a full guarantee.
In order to verify the veracity of the data, we will use the auth / prolongate method.
This is one of the options. In addition to the prolongation, we can also make a request for account / info with the received token - if we can get private data, then everything is ok.
Using it, we can check whether the valid access_token was transferred, and to whom (account_id) it belongs.
If everything is in order, we will record the necessary data in the database, set the cookie for the user - we will do everything that needs to be done with standard authorization with the login / password.

Practice

				array(
					'method'  => 'POST',
					'header'  => 'Content-type: application/x-www-form-urlencoded',
					'content' => http_build_query(
						array(
							'expires_at' => 14*24*60*60,
							'access_token' => $_GET['access_token'],
							'application_id' => APPLICATION_ID
						)
					)
				)
			)
		);
		$data=json_decode(@file_get_contents('https://api.worldoftanks.ru/wot/auth/prolongate/', false, $context),true);//подтверждаем правдивость полученных параметров
		if($data['status']=="ok"){
			$access_token=$data[data][access_token];
			$expires_at=$data[data][expires_at];
			$account_id=$data[data][account_id];
			//здесь вам нужно установить пользователю куки, записать его токен в БД, сделать все то, что сочтете нужным.
			exit('Это пользователь с id '.$account_id.'
Токен '.$access_token.', он подтвержден и действует до '.date("d.m.Y H:i:s",$expires_at).'');
		}else{
			exit('access_token не подтвержден');
		}
	}
}else{
	$error_code=500;
	if(preg_match('/^[0-9]+$/u', $_GET['code'])){
		$error_code=$_GET['code'];
	}
	exit("Произошла ошибка. Код ошибки: $error_code");
}
?>

Demo