Conteúdo


Clientes OAuth 2.0 em programação Java, Parte 3

concessão de código de autorização

Comments

Conteúdos da série:

Esse conteúdo é a parte # de # na série: Clientes OAuth 2.0 em programação Java, Parte 3

Fique ligado em conteúdos adicionais dessa série.

Esse conteúdo é parte da série:Clientes OAuth 2.0 em programação Java, Parte 3

Fique ligado em conteúdos adicionais dessa série.

Visão geral

O OAuth é um padrão aberto para autorização que permite aos clientes obter acesso a recursos protegidos do servidor em nome do proprietário do recurso. O proprietário do recurso pode ser um cliente diferente ou o usuário final. O OAuth também ajuda os usuários finais a autorizar o acesso de terceiros aos seus recursos do servidor sem precisar compartilhar credenciais, como nome de usuário e senha. Esta série de artigos cumpre a estrutura de autorização do OAuth 2.0 descrita em RFC6749. A estrutura de autorização completa do OAuth 2.0, conforme descrita em RFC 6749, pode ser encontrada no website Engineering Task Force (consulte Temas relacionados).

Concessão de autorização

A concessão de autorização é uma credencial que representa a autorização do proprietário do recurso que pode ser usada para acessar um recurso protegido. Essa credencial é usada pelo cliente para obter um token de acesso, e esse token de acesso é, em algum momento, enviado junto com a solicitação para acessar um recurso protegido. O OAuth 2.0 define quatro tipos de concessões:

  1. Código de autorização
  2. Implícita
  3. Credenciais de senha do proprietário do recurso
  4. Credenciais do cliente

Esta série de artigos de quatro partes o conduz pela implementação de um cliente OAuth 2.0 em programação Java™ usando cada um dos tipos de concessão mencionados anteriormente. Nesta terceira parte, explico como implementar a concessão de código de autorização. O artigo explica essa concessão em detalhes e explica o código do cliente de amostra que pode ser usado para fazer interface com qualquer servidor em conformidade com OAuth 2.0 que dê suporte a essa concessão. Até o fim do artigo, você deve ter um entendimento completo da implementação do cliente e estar pronto para fazer o download do código do cliente de amostra para seu próprio teste.

Concessão de código de autorização

Essa concessão é otimizada para clientes confidenciais e usada para obter tokens de acesso e atualização. Esse é um fluxo baseado em redirecionamento e, como tal, o cliente deve poder interagir com o agente do usuário do proprietário do recurso (geralmente, um navegador da web) e também deve ser capaz de aceitar solicitações recebidas (através de redirecionamento) do servidor de autorização.

A concessão de código de autorização é ilustrada no Figura 1.

Figura 1. Fluxo do código de autorização
Flowchart showing                     the authorization code flow
Flowchart showing the authorization code flow

O fluxo ilustrado em Figura 1 inclui as seguintes etapas:

  • (A) O cliente (geralmente, um aplicativo da web) inicia o fluxo direcionando o agente do usuário do proprietário do recurso (geralmente, um navegador da web) para o terminal de autorização. A solicitação do cliente inclui o identificador do cliente, o escopo solicitado, o estado local e o URI de redirecionamento. O servidor de autorização direciona o agente do usuário (geralmente, um navegador da web) de volta para o URI de redirecionamento depois de o acesso ser concedido (ou negado).
  • (B) O proprietário do recurso autentica-se com servidor de autorização por meio do agente do usuário e concede ou nega a solicitação de acesso do cliente.
  • (C) Se o proprietário do recurso conceder acesso, o servidor de autorização redireciona o agente do usuário (geralmente, um navegador da web) de volta para o cliente usando o URI de redirecionamento fornecido anteriormente (na solicitação ou durante o registro do cliente). O URI de redirecionamento inclui um código de autorização e qualquer estado local fornecido pelo cliente anteriormente.
  • (D) O cliente faz uma solicitação de token de acesso do terminal do token do servidor de autorização incluindo o código de autorização recebido na etapa anterior. Ao fazer a solicitação, o cliente autentica com o servidor de autorização usando as credenciais do cliente. O cliente também inclui o URI de redirecionamento usado para obter o código de autorização para verificação.
  • (E) O servidor de autorização autentica o cliente. Ele valida o código de autorização e garante que o URI de redirecionamento recebido corresponda ao URI usado para redirecionar o cliente na etapa (C). Se for válido, o servidor de autorização responde com um token de acesso e, opcionalmente, um token de atualização, caso um acesso offline tenha sido solicitado.

Solicitação de código de autorização

A solicitação de código de autorização corresponde às etapas (A) e (B) como descrito em Figura 1. Na etapa (A), o cliente faz uma solicitação para o servidor de autorização no formato application/x-www-form-urlencoded , como mostrado em Lista 1.

Lista 1. Exemplo de uma solicitação de código de autorização
GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com

A solicitação deve conter os seguintes parâmetros:

  • response_type: obrigatório. O valor deve ser definido para code.
  • client_id: obrigatório. O ID do cliente.
  • redirect_uri: obrigatório. Usado para redirecionamento do agente do usuário.
  • scope: opcional. O escopo da solicitação de acesso.
  • state: opcional. Para manter o estado entre a solicitação e o retorno de chamada.

Depois de a solicitação ser verificada pelo servidor de autorização, o servidor enviará uma resposta de redirecionamento HTTP código 302 ao cliente. A resposta também incluirá um URI de redirecionamento no cabeçalho http Location . Na etapa (B), o cliente deve redirecionar o agente do usuário (tipicamente, um navegador da web) para esse URI. Esse URI de redirecionamento normalmente é uma página de login em que o proprietário do recurso pode se conectar com suas credenciais e conceder/revogar acesso à solicitação do cliente.

Resposta do código de autorização

A resposta do código de autorização é mostrada na etapa (C) de Figura 1. Se o proprietário do recurso conceder a solicitação de acesso, o servidor de autorização emite um código de autorização. O servidor de autorização redireciona o agente do usuário para o URI de redirecionamento fornecido como parte da solicitação na etapa (A) e inclui o código de autorização como parte do componente de consulta do URI de redirecionamento usando o formato application/x-www-form-urlencoded .

Os parâmetros do URI são os seguintes:

  • Code: obrigatório. O código de autorização gerado pelo servidor de autorização. O código é temporário e deve expirar logo depois de ter sido gerado. O cliente não deve usar o código de autorização mais de uma vez. Quaisquer outras solicitações usando o mesmo código devem ser revogadas pelo servidor de autorização. O código de autorização é limitado ao identificador do cliente e ao URI de redirecionamento.
  • State: obrigatório. Se o parâmetro state estiver presente na solicitação de código de autorização do cliente, ele deverá ser definido para o valor exato recebido do cliente.

Solicitação de token de acesso

Isso corresponde à etapa (D) em Figura 1. O cliente faz uma solicitação ao terminal do token (servidor de autorização) usando o formato application/x-www-form-urlencoded como mostrado em Lista 2.

Lista 2. Exemplo de uma solicitação de token de acesso
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

             grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
             &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom&client_id=c342

A solicitação de token de acesso deve ter os seguintes parâmetros definidos:

  • grant_type: obrigatório. O valor deve ser definido para authorization_code.
  • client_id: obrigatório. O ID do cliente.
  • client_secret: opcional. Segredo. Para autenticar com o servidor de autorização.
  • code: obrigatório. O código de autorização recebido do servidor.
  • redirect_uri: obrigatório. Idêntico ao enviado na etapa (A).

O servidor de autorização verifica se o código e o URI de redirecionamento são válidos. No caso de clientes confidenciais, o servidor de autorização também autentica o cliente usando suas credenciais de cliente enviadas no corpo da solicitação ou no cabeçalho de autorização.

Resposta do token de acesso

Isso corresponde à etapa (E) em Figura 1. Se a solicitação de token de acesso for válida e autorizada, o servidor de autorização retorna o token de acesso em uma resposta de token de acesso. Um exemplo de uma resposta bem-sucedida é mostrado em Lista 3.

Lista 3. Exemplo de uma resposta de token de acesso bem-sucedida
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
  "access_token":"2YotnFZFEjr1zCsicMWpAA",
  "token_type":"Bearer",
  "expires_in":3600,
  "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
  "example_parameter":"example_value"
}

Se a solicitação não for válida ou não for autorizada, o servidor de autorização retorna uma mensagem de erro adequada com código.

Solicitação de atualizar token de acesso

Essa é uma etapa opcional aplicável se o cliente tiver solicitado acesso offline e tiver recebido um refresh_token como parte da solicitação de token de acesso. Um token de acesso é temporário e geralmente expira depois de uma hora. Depois da expiração do token de acesso, o cliente precisaria repetir o processo de autenticação e o proprietário do recurso precisaria efetuar login e fornecer autorização para permitir ao cliente fazer a solicitação de token de acesso novamente.

Se o cliente precisar atualizar tokens de acesso enquanto o proprietário do recurso não estiver presente no navegador para efetuar login e autenticar, o cliente usa o acesso offline. O cliente pode solicitar um acesso offline enquanto faz a primeira solicitação de código de autorização (consulte a etapa (A)). Sob esse esquema, o servidor de autorização retorna um token de atualização além do token de acesso. O token de atualização é um token de vida longa que não expira, a menso que seja explicitamente revogado pelo proprietário do recurso. Sempre que o token de acesso expira, o cliente pode usar o token de atualização para gerar novamente um token de acesso sem o proprietário do recurso precisar conectar-se e autorizar a solicitação de acesso.

O cliente faz uma solicitação ao terminal do token (servidor de autorização) usando o formato application/x-www-form-urlencoded , como mostrado em Lista 4:

Lista 4. Solicitação ao terminal do token
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA

Os parâmetros da solicitação são definidos da seguinte maneira:

  • grant_type: obrigatório. O valor deve ser definido para refresh_token.
  • refresh_token: obrigatório. Isso é recuperado anteriormente da solicitação do token de acesso.
  • scope: opcional. O escopo da solicitação de acesso.

O servidor de autorização verifica o token de atualização e emite um novo token de acesso.

Atualizar resposta do token de acesso

Se a solicitação for bem-sucedida, o servidor de autorização retorna um novo token de acesso. Um exemplo de reposta bem-sucedida é mostrado em Lista 5.

Lista 5. Atualizar resposta do token de acesso
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
  "access_token":"2YotnFZFEjr1zCsicMWpAA",
  "token_type":"Bearer",
  "expires_in":3600,
  "example_parameter":"example_value"
}

Se a solicitação não for válida ou não for autorizada, o servidor de autorização retorna uma mensagem de erro adequada com código.

Setup

O cliente Outh2.0 de amostra é um projeto da web dinâmico. É possível fazer o download de um arquivo .war contendo o projeto e o código-fonte de Recursos para download. Você pode importar o arquivo .war para seu ambiente do Eclipse.

Pré-requisitos

É necessário o IDE do Eclipse para desenvolvedores de Java EE para configurar o ambiente de desenvolvimento e importar o projeto conectado. É possível fazer o download do Eclipse da página Eclipse downloads.

É preciso ter o contêiner JSP/Servlet do Apache Tomcat para executar o web client OAuth 2.0. É possível fazer o download do Tomcat a partir de Página de download do Apache Tomcat.

Dependências

O projeto de código do cliente depende dos seguintes arquivos JAR:

  1. commons-codec-1.6.jar
  2. commons-logging-1.1.1.jar
  3. httpclient-4.2.5.jar
  4. httpclient-cache-4.2.5.jar
  5. httpcore-4.2.4.jar
  6. httpmime-4.2.5.jar
  7. json-simple-1.1.1.jar

Os arquivos JAR mencionados nos pontos 1 a 6 podem ser encontrados no arquivo JAR HttpComponents , que pode ser transferido por download da página de download HttpComponents Downloads. O arquivo json-simple-1.1.1.jar pode ser transferido por download do projeto JSON Simple. Certifique-se de copiar esses jars para a pasta lib do diretório de instalação do Apache Tomcat. Alguns dos arquivos JAR necessários podem já estar disponíveis por padrão no Tomcat, assim, você precisa apenas copiar os faltantes.

Importar o arquivo .war do projeto para o Eclipse

Depois de ter o Eclipse e o Apache Tomcat instalados, é preciso importar o arquivo .war da seção Recursos para download . Para importar o arquivo war, siga estas etapas simples descritas no website do Eclipse em Importando arquivos archive web (WAR)."

Certifique-se de associar o servidor Tomcat ao seu projeto enquanto importa o arquivo .war para o Eclipse. É preciso selecionar a versão do Tomcat e fornecer o caminho para o diretório raiz de instalação do Tomcat para concluir a configuração.

É possível obter instruções mais detalhadas sobre como associar o servidor Tomcat ao seu projeto em "Creating a Tomcat server."

Depois de importar com sucesso o arquivo .war para a área de trabalho do Eclipse, você encontrará o código-fonte sob Java Resources/src na hierarquia do projeto.

Executar o cliente OAuth 2.0

Depois de o arquivo .war ter sido importado com sucesso e o Tomcat ter sido configurado com os arquivos JAR necessários, é possível executar o cliente clicando com o botão direito no nome do projeto OAuth2.0_AuthCode e selecionando Run As e Run on Server.

Isso implementa o cliente no servidor e carrega a página index.html no navegador interno do Eclipse. Pessoalmente, prefiro interagir com o web client em um navegador externo.

É possível acessar o web client a partir de qualquer navegador acessando: http://localhost:8080/OAuth2.0_AuthCode.

Seções subsequentes o conduzem pelo código do cliente em detalhes e mostram como testar esse cliente com servidores em conformidade com OAuth 2.0 populares, como Salesforce, Google e IBM.

Código do cliente OAuth 2.0

O cliente OAuth 2.0 de amostra deste artigo implementa a concessão de código de autorização. O código do cliente de amostra é um aplicativo da web, em vez de um projeto Java regular, que era o caso para os tipos de concessão discutidos em artigos anteriores. Isso ocorre porque o fluxo de concessão de código de autorização é feito para atender aplicativos da web e é otimizado para um agente do usuário, que geralmente é um navegador da web.

Parâmetros de entrada

Os parâmetros de entrada para o cliente precisam ser fornecidos usando o arquivo de propriedades Oauth2Client.config que está disponível sob a pasta src no projeto. Os parâmetros de entrada são:

  • scope: este é um parâmetro opcional. Ele representa o escopo da solicitação de acesso. O token de acesso retornado pelo servidor tem acesso a apenas os serviços mencionados no escopo.
  • state: este é um parâmetro opcional. É usado para manter um estado entre a solicitação do cliente e a resposta de redirecioanamento do servidor de autorização com o propósito de garantir a integridade do cliente.
  • grant_type: precisa ser definido para authorization_code representando o tipo de concessão do código de autorização.
  • client_id: o ID do cliente ou do consumidor fornecido pelo servidor de recursos ao registrar o aplicativo com ele.
  • client_secret: o segredo do cliente ou do consumidor fornecido pelo servidor de recurso ao registrar o aplicativo com ele.
  • access_token: o token de acesso retornado pelo terminal do token em resposta a uma solicitação de token de acesso válida e autorizada. O código de autorização retornado pelo servidor de autorização é trocado por um token de acesso.
  • refresh_token: o token de atualização retornado pelo terminal do token em resposta a uma solicitação de token de acesso autorizada. O token de atualização pode ser usado para atualizar um token de acesso expirado sem precisar que o proprietário do recurso esteja presente para autenticação novamente. O cliente precisa solicitar explicitamente o token de atualização do servidor.
  • redirect_uri: o URI para o qual o servidor de autorização redirecionará o agente do usuário como parte da solicitação de código de autorização. O código de autorização é enviado para esse URI.
  • authentication_server_url: representa o servidor de autorização. Todas as solicitações para obter o código de autorização precisam ser enviadas a essa URL.
  • token_endpoint_url: representa o terminal do token. Todas as solicitações para obter tokens de acesso e atualizar tokens de acesso por meio da solicitação de atualizar token precisam ser enviadas a essa URL.
  • resource_server_url: representa a URL do servidor de recurso que precisa ser contatado para acessar um recurso protegido enviando a ele o token de acesso no cabeçalho de autorização.
  • approval_prompt_key: o nome da propriedade usada pelo servidor de autorização para definir a condição do prompt de aprovação. Em geral, cada servidor de autorização (Salesforce, Google, IBM, e assim por diante) tem uma propriedade customizada que precisa ser enviada como parte de uma solicitação de código de autorização para indicar se o cliente deseja impingir o prompt de aprovação para cada solicitação. O nome da propriedade para Google é approval_prompt. Para o Salesforce, é login consent.
  • access_type_key: o nome da propriedade usado pelo servidor de autorização para definir a condição de tipo de acesso. Em geral, cada servidor de autorização (Salesforce, Google, IBM, e assim por diante) tem um método customizado pelo qual o cliente pode pedir que um token de atualização seja emitido junto com o token de acesso como parte da solicitação do token de acesso. O Google faz isso fornecendo a propriedade access_type . O Salesforce exige que você insira o valor refresh_token como parte do escopo.
  • access_type_value: o valor para a propriedade access_type_key . Para o Google, é preciso enviar o valor offline para o servidor incluir o token de atualização além do token de acesso.

Figura 2 mostra a página index.html do código do cliente de amostra. Você deve ver essa página depois de ter configurado com sucesso o projeto no Eclipse e implementado-o no Tomcat.

Figura 2. Página inicial do cliente deteste
Screen image of the                     OAuth 2.0 index page
Screen image of the OAuth 2.0 index page

O cliente expõe duas operações fundamentais do OAuth 2.0 que precisam ser entendidas. Primeiro, o cliente mostra como obter um token de acesso do servidor. Segundo, o cliente mostra como usar um token de acesso existente para acessar um recurso protegido do servidor.

Para executar o cliente:

  • Primeiro coloque todos os valores requeridos no arquivo Oauth2Client.config.
  • Clique em Start Test para o token Get Access. uma solicitação HTTP GET é enviada ao servlet OAuth2Client, que está acessível no seguinte URI http://localhost:8080/OAuth2.0_AuthCode/handler.
  • O código de interface do usuário envia o seguinte parâmetro de consulta como parte da chamada para o servlet OAuth2Client: caller=token (access token request), caller=resource (access protected resource request).

O código do cliente em Lista 6 é um extrato do método doGet da classe OAuth2Client.

Lista 6. Extrato do método doGet do cliente de amostra
String caller = request.getParameter(OAuthConstants.CALLER);
String code = request.getParameter(OAuthConstants.CODE);
		
//Load the properties file
Properties config = OAuthUtils.getClientConfigProps(OAuthConstants.CONFIG_FILE_PATH);
				
//Generate the OAuthDetails bean from the config properties file
OAuth2Details oauthDetails = OAuthUtils.createOAuthDetails(config);
				
//Validate Input
List<String> invalidProps = OAuthUtils.validateInput(oauthDetails);
	if(invalidProps!=null && invalidProps.size() == 0){
		//Validation successful
			
		if(OAuthUtils.isValid(caller)){
			//Request was sent from web application.
			//Check type of request
			if(caller.equalsIgnoreCase(OAuthConstants.TOKEN)){
				//Request for Access token
				oauthDetails.setAccessTokenRequest(true);
				String location = 			 		
				OAuthUtils.getAuthorizationCode(oauthDetails);
					
				//Send redirect to location returned by endpoint
				response.sendRedirect(location);
				return;
		}
		else{
			//Request for accessing protected resource
				if(!OAuthUtils.isValid(oauthDetails.getResourceServerUrl())){
					invalidProps.add(OAuthConstants.RESOURCE_SERVER_URL);
						
				}
					
				if(!OAuthUtils.isValid(oauthDetails.getAccessToken())){
					if(!OAuthUtils.isValid(oauthDetails.getRefreshToken())){
						invalidProps.add(OAuthConstants.REFRESH_TOKEN);
					}
						
				}
					
					
				if(invalidProps.size() > 0){
					sendError(response, invalidProps);
					return;
				}
					
				Map<String,String> map = OAuthUtils.getProtectedResource(oauthDetails);
				response.getWriter().println(new Gson().toJson(map));
				return;
			}
		}
		else if(OAuthUtils.isValid(code)){
			//Callback from endpoint with code.
			Map<String,String> map = OAuthUtils.getAccessToken(oauthDetails, code);
			response.getWriter().println(new Gson().toJson(map));
			return;
		}
		else{
			//Invalid request/error response
			String queryString = request.getQueryString();
			String error = "Invalid request";
			if(OAuthUtils.isValid(queryString)){
				//Endpoint returned an error
				error = queryString;
			}
			response.getWriter().println(error);
			return;
				
			}
		}
		else{
			//Input is not valid. Send error
			sendError(response, invalidProps);
			return;
			
		}

Observações sobre Lista 6:

  • O cliente recupera os parâmetros de consulta, caller e code. Se a solicitação tiver sido enviada pela interface do usuário como mostrado anteriormente, o parâmetro caller terá um valor válido; caso contrário, a solicitação foi enviada do servidor de autorização como parte da chamada de redirecionamento e code terá um valor válido.
  • O código do cliente então cria um bean OAuthDetails lendo as propriedades fornecidas no arquivo OAuth2Client.config .
  • A correção e a completude do bean então são validadas. Se qualquer propriedade inválida ou ausente for encontrada, uma resposta de erro adequada com as propriedades ausente/incorreto é enviada à interface com o usuário.
  • O código do cliente continua a verificação da operação solicitada e a operação adequada é chamada.

Solicitação de token de acesso

O código em Lista 7 demonstra como fazer a solicitação de código de autorização.

Lista 7. Código da solicitação de código de autorização
HttpPost post = new HttpPost(oauthDetails.getAuthenticationServerUrl());
String location = null;

String state = oauthDetails.getState();

List<BasicNameValuePair> parametersBody = new ArrayList<BasicNameValuePair>();

parametersBody.add(new BasicNameValuePair(OAuthConstants.RESPONSE_TYPE,
		OAuthConstants.CODE));

parametersBody.add(new BasicNameValuePair(OAuthConstants.CLIENT_ID,
		oauthDetails.getClientId()));

parametersBody.add(new BasicNameValuePair(OAuthConstants.REDIRECT_URI,
		oauthDetails.getRedirectURI()));

if (isValid(oauthDetails.getScope())) {
	parametersBody.add(new BasicNameValuePair(OAuthConstants.SCOPE,
			oauthDetails.getScope()));
}

if (isValid(oauthDetails.getApprovalPromptValue())) {
	parametersBody.add(new BasicNameValuePair(
			oauthDetails.getApprovalPromptKey(), oauthDetails
					.getApprovalPromptValue()));
}
		
if (isValid(oauthDetails.getAccessTypeValue())) {
	parametersBody.add(new BasicNameValuePair(
			oauthDetails.getAccessTypeKey(), oauthDetails
					.getAccessTypeValue()));
}

if (isValid(state)) {
	parametersBody.add(new BasicNameValuePair(OAuthConstants.STATE,
			oauthDetails.getState()));
}

DefaultHttpClient client = new DefaultHttpClient();
HttpResponse response = null;
String accessToken = null;
try {
	post.setEntity(new UrlEncodedFormEntity(parametersBody, HTTP.UTF_8));

	response = client.execute(post);
	int code = response.getStatusLine().getStatusCode();
	System.out.println("Code " + code);
	Map<String, String> map = handleURLEncodedResponse(response);

	if (OAuthConstants.HTTP_SEND_REDIRECT == code) {
		location = getHeader(response.getAllHeaders(),
				OAuthConstants.LOCATION_HEADER);
		if (location == null) {
			System.out
					.println("The endpoint did not pass in valid location header for redirect");
			throw new RuntimeException(
					"The endpoint did not pass in valid location header for redirect");
		}
	} else {
	System.out
				.println("Was expecting code 302 from endpoint to indicate redirect. Recieved httpCode "
						+ code);
		throw new RuntimeException(
				"Was expecting code 302 from endpoint to indicate redirect. Recieved httpCode "
						+ code);
	}

} catch (ClientProtocolException e) {
	// TODO Auto-generated catch block
	e.printStackTrace();
	throw new RuntimeException(e.getMessage());
} catch (IOException e) {
	// TODO Auto-generated catch block
	e.printStackTrace();
	throw new RuntimeException(e.getMessage());
}

return location;

Observações sobre o código em Lista 7:

  • O código começa criando um método HttpPost , que é usado para enviar parâmetros codificados em URL.
  • response_type, client_id e redirect_uri são parâmetros obrigatórios e estão incluídos na solicitação.
  • Outros parâmetros opcionais como state, scope, approval_prompt_key/value e access_type_key/value são incluídos se seus valores válidos forem fornecidos no arquivo de configuração.
  • Um DefaultHttpClient é usado para fazer a solicitação ao servidor de autorização.
  • O servidor de autorização valida os parâmetros de solicitação e replica com um código de redirecionamento 302 HTTP junto com o cabeçalho Location .
  • O código reconhece o 302 recebido do servidor de autorização recuperar o cabeçalho de Location dos cabeçalhos de resposta.
  • O cabeçalho Location contém o URI que o cliente precisa para redirecionar o agente do usuário (navegador da web). O URI é geralmente um prompt de login para o proprietário do recurso entrar e fornecer aprovação ao cliente.
  • O valor para o URI de local é retornado para o método de chamada (OAuth2Client.doGet()).
  • O método Oauth2Client.doGet() redireciona a resposta ao URI de localização.
  • O agente do usuário do proprietário do recurso (navegador da web) agora é redirecionado para uma página de login/página de autorização em que o proprietário do recurso precisa efetuar sign in e fornecer aprovação ao cliente que está fazendo a solicitação.
  • Depois de o proprietário do recurso dar aprovação ao cliente, o servidor de autorização usa o URI de redirecionamento enviado na solicitação de código de autorização original para enviar o code.

O código em Lista 8 mostra como a solicitação do token de acesso final é feita usando o código recebido na etapa anterior.

Lista 8. Solicitação do token de acesso do código de amostra
HttpPost post = new HttpPost(oauthDetails.getTokenEndpointUrl());
		String clientId = oauthDetails.getClientId();
		String clientSecret = oauthDetails.getClientSecret();
		String scope = oauthDetails.getScope();
		Map<String, String> map = new HashMap<String, String>();

		List<BasicNameValuePair> parametersBody = new ArrayList<BasicNameValuePair>();

		parametersBody.add(new BasicNameValuePair(OAuthConstants.GRANT_TYPE,
				oauthDetails.getGrantType()));

		parametersBody.add(new BasicNameValuePair(OAuthConstants.CODE,
				authorizationCode));

		parametersBody.add(new BasicNameValuePair(OAuthConstants.CLIENT_ID,
				clientId));

		if (isValid(clientSecret)) {
			parametersBody.add(new BasicNameValuePair(
					OAuthConstants.CLIENT_SECRET, clientSecret));
		}

		parametersBody.add(new BasicNameValuePair(OAuthConstants.REDIRECT_URI,
				oauthDetails.getRedirectURI()));

		DefaultHttpClient client = new DefaultHttpClient();
		HttpResponse response = null;
		String accessToken = null;
		try {
			post.setEntity(new UrlEncodedFormEntity(parametersBody, HTTP.UTF_8));

			response = client.execute(post);
			int code = response.getStatusLine().getStatusCode();

			map = handleResponse(response);
			accessToken = map.get(OAuthConstants.ACCESS_TOKEN);

		} catch (ClientProtocolException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
			throw new RuntimeException(e.getMessage());
		} catch (IOException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
			throw new RuntimeException(e.getMessage());
		}

		return map;

Observações sobre Lista 8:

  • O código usa um método HttpPost para fazer a solicitação do token de acesso ao terminal do token.
  • grant_type, code, client_id e redirect_uri são parâmetros obrigatórios.
  • Se o client_secret for válido, ele é incluído na solicitação também.
  • O valor para code é o código retornado pelo servidor de autorização na solicitação anterior.
  • Se a solicitação for válida, o terminal do token retorna o token de acesso e um token de atualização se a solicitação tiver sido para acesso offline.
  • Observe que o URI de redirecionamento enviado como parte dessa solicitação precisa ser idêntico ao enviado como parte da solicitação de código de autorização. O terminal do token valida que o URI de redirecionamento corresponde ao especificado no aplicativo do cliente cujos dados estão disponíveis com o terminal do token.

Token de acesso de atualização

Como já mencionado, o token de acesso costuma ter uma natureza temporária, com um tempo de vida típico de uma hora. Ter um token de atualização permite ao cliente atualizar um token de acesso expirado de modo automático sem precisar que o proprietário do recurso se conecte e autentique o cliente outra vez. O código em Lista 9 ilustra isso.

Lista 9. Código de amostra para o token de acesso de atualização
String clientId = oauthDetails.getClientId();
String clientSecret = oauthDetails.getClientSecret();
String scope = oauthDetails.getScope();
String refreshToken = oauthDetails.getRefreshToken();
Map<String, String> map = new HashMap<String, String>();

		if (!isValid(refreshToken)) {
			throw new RuntimeException(
					"Please provide valid refresh token in config file");
		}

		List<BasicNameValuePair> parametersBody = new ArrayList<BasicNameValuePair>();

		parametersBody.add(new BasicNameValuePair(OAuthConstants.GRANT_TYPE,
				OAuthConstants.REFRESH_TOKEN));

		parametersBody.add(new BasicNameValuePair(OAuthConstants.REFRESH_TOKEN,
				oauthDetails.getRefreshToken()));

		if (isValid(clientId)) {
			parametersBody.add(new BasicNameValuePair(OAuthConstants.CLIENT_ID,
					clientId));
		}

		if (isValid(clientSecret)) {
			parametersBody.add(new BasicNameValuePair(
					OAuthConstants.CLIENT_SECRET, clientSecret));
		}

		if (isValid(scope)) {
			parametersBody.add(new BasicNameValuePair(OAuthConstants.SCOPE,
					scope));
		}

		DefaultHttpClient client = new DefaultHttpClient();
		HttpResponse response = null;
		try {
			post.setEntity(new UrlEncodedFormEntity(parametersBody, HTTP.UTF_8));

			response = client.execute(post);
			int code = response.getStatusLine().getStatusCode();

			map = handleResponse(response);

		} catch (ClientProtocolException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
			throw new RuntimeException(e.getMessage());
		} catch (IOException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
			throw new RuntimeException(e.getMessage());
		}

		return map;

Observações sobre Lista 9:

  • O código usa um método HttpPost para enviar a solicitação ao terminal do token.
  • Os parâmetros grant_type e refresh_token são obrigatórios.
  • Se forem válidos, client_id, client_secret e scope são incluídos também.
  • Se a solicitação for válida, o terminal do token retorna um novo token de acesso.

Acessar um recurso protegido

O código em Lista 10 demonstra como acessar um recurso protegido usando o token de acesso. Se o token de acesso estiver expirado, o código atualiza o token de acesso e então tenta acessar novamente o recurso protegido.

Lista 10. Código de amostra para acessar um recurso protegido
String resourceURL = oauthDetails.getResourceServerUrl();

		Map<String, String> map = new HashMap<String, String>();

		HttpGet get = new HttpGet(resourceURL);
		get.addHeader(OAuthConstants.AUTHORIZATION,
				getAuthorizationHeaderForAccessToken(oauthDetails
						.getAccessToken()));
		DefaultHttpClient client = new DefaultHttpClient();
		HttpResponse response = null;
		String accessToken = null;
		int code = -1;
		try {
			response = client.execute(get);
			code = response.getStatusLine().getStatusCode();
			if (code == OAuthConstants.HTTP_UNAUTHORIZED
					|| code == OAuthConstants.HTTP_FORBIDDEN) {
				// Access token is invalid or expired.Regenerate the access
				// token
				System.out
						.println("Access token is invalid or expired. Refreshing access token....");
				map = refreshAccessToken(oauthDetails);
				accessToken = map.get(OAuthConstants.ACCESS_TOKEN);

				if (isValid(accessToken)) {
					// update the access token
					System.out.println("New access token: " + accessToken);
					oauthDetails.setAccessToken(accessToken);
					get.removeHeaders(OAuthConstants.AUTHORIZATION);
					get.addHeader(OAuthConstants.AUTHORIZATION,
							getAuthorizationHeaderForAccessToken(oauthDetails
									.getAccessToken()));
					get.releaseConnection();
					response = client.execute(get);
					code = response.getStatusLine().getStatusCode();
					if (code >= 400) {
						throw new RuntimeException(
								"Could not access protected resource. Server returned http code: "
										+ code);

					}

				} else {
	throw new RuntimeException("Could not refresh access token");
				}

			}

			map = handleResponse(response);

		} catch (ClientProtocolException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		} catch (IOException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		} finally {
			get.releaseConnection();
		}

		return map;

Observações sobre Lista 10:

  • Esse método aceita o bean OauthDetails com os valores recuperados do arquivo de configuração.
  • Como o nome sugere, esse método usa um método HttpGet simples para tentar recuperar um recurso protegido do servidor de recursos.
  • Para autenticar com o servidor de recursos, o token de acesso precisa ser enviado como parte do cabeçalho de autorização. Por exemplo, Authorization: Bearer accessTokenValue.
  • O código cria um DefaultHttpClient para fazer a solicitação get ao servidor de recursos.
  • Se o código de resposta recebido do servidor de recursos for 401 ou 403, o token de acesso usado para autenticação provavelmente expirou ou é inválido.
  • A próxima etapa é gerar novamente o token de acesso (consulte Lista 9).
  • Depois ode o token de acesso ter sido gerado novamente com sucesso, o código atualiza o valor do token de acesso no bean OauthDetails . O código também substitui o cabeçalho de autorização existente em get pelo novo valor do token de acesso.
  • O código agora faz outra solicitação para acessar o recurso protegido.
  • Se o token de acesso for válido e a URL do servidor de recurso estiver correta, você deve poder ver os conteúdos da resposta no console.

Testar o cliente com Salesforce.com

Registrando-se com Salesforce.com

Salesforce.com é um aplicativo de software como serviço (SaaS) popular com suporte para o tipo de concessão de código de autorização para OAuth 2.0.

Para registrar-se com Salesforce.com:

  1. Clique em Login e, em seguida, clique em Inscreva-se grátis.
  2. Complete o registro para receber suas credenciais.
  3. Além de um nome de usuário e senha, você também recebe um token de segurança. A senha fornecida para fazer uma solicitação de token de acesso precisa ser uma concatenação da sua senha e token de segurança (por exemplo, password12312123).
  4. Consulte Temas relacionados para um link para um artigo útil sobre como criar um aplicativo no salesforce.com.
  5. O URI de redirecionamento que você especifica durante a criação do aplicativo é usado pelo salesforce.com para comunicar-se com o tipo de concessão de Código de Autorização.

Executando o cliente de amostra com o Salesforce.com

Agora que você configurou o servidor em conformidade com OAuth 2.0 em Salesforce, você está pronto para testar seu cliente e recuperar informações protegidas do servidor.

É possível encontrar o arquivo Oauth2Client_salesforce.config sob a pasta Java resources/src. Esse arquivo de configuração é customizado para salesforce.com e pode ser usado como um modelo para fornecer valores de configuração para testar com relação a Salesforce.com.

Execute o aplicativo da web Oauth2Client no servidor Tomcat, como mostrado anteriormente, para chegar à página inicial do cliente de teste, como mostra Figura 3.

Figura 3. Página do cliente de teste do Salesforce
Test client start                     page
Test client start page

Figura 3 mostra a página do cliente de teste. Clique em Start Test para o token Get Access. Em seguida, você verá o prompt de login para a solicitação do token de acesso do Salesforce, como mostra Figura 4.

Figura 4. Solicitação de token de acesso do Salesforce (prompt de login)
Salesforce.com log                     in window
Salesforce.com log in window

Figura 4 mostra a página de login do Salesforce para a qual o cliente redirecionou o agente do usuário (navegador da web) depois de 302 e o cabeçalho Location ter sido recebido do Salesforce.com.

Depois de efetuar login, você verá o prompt de aprovação da solicitação do token de acesso do Salesforce como mostra Figura 5.

Figura 5. Solicitação de token de acesso do Salesforce (prompt de aprovação)
Access request                     screen
Access request screen

Figura 5 mostra o prompt de aprovação para o proprietário do recurso (pós-login) para conceder acesso ao aplicativo VarunOAuth2.0, que é o código de amostra solicitando acesso aos dados do proprietário do recurso.

Saída do token de acesso do Salesforce

Depois de conceder acesso ao cliente no prompt de aprovação do Salesforce, o terminal do token responde com o acesso e atualiza tokens junto com outros dados específicos do Salesforce. Você deve ver a saída na janela do console do Eclipse, como mostra Lista 11.

Lista 11. Saída do token de acesso do Salesforce
********** Response Received **********
  id = https://login.salesforce.com/id/00D90000000mQaYEAU/00590000001HCB7AAO
  issued_at = 1408356835704
  scope = full refresh_token
  instance_url = https://ap1.salesforce.com
  token_type = Bearer
  refresh_token = 5Aep8617VFpoP.M.4vPT_5eQXhIJTvFPNyK2GaBz7xFooRQE590MJSZNVqfTXKUqoiZH_yhm_ZpaVsmp
  id_token = eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjE5MCJ9.eyJleHAiOjE0MDgzNTY5NTUsInN1YiI6Imh0dHBzOi8vbG9naW4uc2FsZXNmb3JjZS5jb20vaWQvMDBEOTAwMDAwMDBtUWFZRUFVLzAwNTkwMDAwMDAxSENCN0FBTyIsImF0X2hhc2giOiJ3eWJpZ1NRTEtaNjdiYlRxWUJxNEVnIiwiYXVkIjoiM01WRzlZNmRfQnRwNHhwNXhLcHgxcFBtcFZidnlUV09Gd2FWbkxwOFpDYjRZVjBRX2FJcHI2WTZVazd1ZHcxcWtCTFZQcVVFNWY2blU1NW5xTWljMCIsImlzcyI6Imh0dHBzOi8vbG9naW4uc2FsZXNmb3JjZS5jb20iLCJpYXQiOjE0MDgzNTY4MzV9.W-r2-k-creIijmRmZ5qQff-bonjjtynNivJAv5XaSGedGhPavWlQpmn76B9k5vB7TWUDTX6y2NroTuIpBi-F2jrO0dunN1giPfv-YKyrCYrpy75J7NXmnSnDGrKhhYgkcR7x9s9MLMoMD-Vf1wsJr58XU2He-UwfrihfkdJzvLKiWRNQfz1gCUwlNSws70AQSqrBfB6MHpLqE7ogG1M3SOp6B4hbcA8NC_zwnvJwIDmF4t3_rf6VsgPuPjV_t4PphBhbrln7sm4b9OMcRRycc8WcCvgBvNPjI37uImciDYUGIP25NEy5sRM3mEU392YlmR5AoHUqOVOqdO9DS1ULWxBy3Q-Fp1wyKYyWiCrUMXe5QdtmeBmkpzptCKXwAhfxhLBdai4bBFfh8K3If4UP-WeNcpMwNkiRhVElwntlqtCPaSs4BLiZGonpLLgwET-f_Iyxs4BauCNvyWDbme_2it2V5AEHgJoKvuf2oU6hD8-Sit8MsdEdc2ugf-nk96QJt5px3QvChfDIE8B7W5trzXagkvzVcXXJV06zJbDUf-ioz7zDTI4Popkxlb31cQiaLAtz2IxIUtjZAfAcTXJaxi8txjV8glqS8Z61145bUaitXgGmZhZAqeefrqLneyCDD--EPNWDIdQYSPhRPbtFb5Aa89AMDNIePxTNnIWShNs
  access_token = 00D90000000mQaY!AQ8AQMgSI4eZOjvKJGVPuWISCkuS1WC0R6gOWpMg57bMwVWGkyS9_Wraa5ooMrjTfaqMmXmXlgParPk1rjn0vH5BxbNRq3W0
  signature = o1VBoC/PzvMw08hZGxYvXLiV/SXQirHBl8qOrk1Mu6Q=

Recuperando informações do usuário do servidor Salesforce

Agora que você possui o token de acesso, é possível fazer uma solicitação para acessar as informações da conta do proprietário do recurso de Salesforce, que exige autenticação OAuth 2.0.

Atualize o arquivo Oauth2Client.confg com o token de acesso e o token de atualização. Também defina a propriedade de URL do servidor de recurso com a URL do servidor de recurso que deseja testar novamente. Por exemplo, é possível defini-la para o campo id retornado pelo Salesforce como parte da resposta do token de acesso. Esse campo de id é usado para acessar as informações da conta do proprietário do recurso (por exemplo, https://login.salesforce.com/id/00D90000000mQaYEAU/00590000001HCB7AAO).

Atualize o projeto e execute-o novamente no servidor Tomcat. Clique em Start Test para acessar o recurso protegido.

A janela do console do Eclipse deve mostrar uma saída similar a Lista 12.

Lista 12. Saída de recurso protegido do Salesforce
********** Response Received **********
  addr_city = null
  email_verified = true
  locale = en_US
  addr_state = Unknown
  asserted_user = true
  nick_name = vern.ojha1********
  id = https://login.salesforce.com/id/00D9000000QaYEAU/005900001HCB7AAO
  first_name = varun
  timezone = America/Los_Angeles
  username = *******
  mobile_phone = null
  user_id = ************
  addr_street = null
  status = {"created_date":null,"body":null}
  user_type = STANDARD
  urls = {"sobjects":"https:\/\/ap1.salesforce.com\/services\/data\/v{version}\/sobjects\/","feeds":"https:\/\/ap1.salesforce.com\/services\/data\/v{version}\/chatter\/feeds","users":"https:\/\/ap1.salesforce.com\/services\/data\/v{version}\/chatter\/users","query":"https:\/\/ap1.salesforce.com\/services\/data\/v{version}\/query\/","enterprise":"https:\/\/ap1.salesforce.com\/services\/Soap\/c\/{version}\/00D90000000mQaY","recent":"https:\/\/ap1.salesforce.com\/services\/data\/v{version}\/recent\/","feed_items":"https:\/\/ap1.salesforce.com\/services\/data\/v{version}\/chatter\/feed-items","search":"https:\/\/ap1.salesforce.com\/services\/data\/v{version}\/search\/","partner":"https:\/\/ap1.salesforce.com\/services\/Soap\/u\/{version}\/00D90000000mQaY","rest":"https:\/\/ap1.salesforce.com\/services\/data\/v{version}\/","groups":"https:\/\/ap1.salesforce.com\/services\/data\/v{version}\/chatter\/groups","metadata":"https:\/\/ap1.salesforce.com\/services\/Soap\/m\/{version}\/00D90000000mQaY","profile":"https:\/\/ap1.salesforce.com\/0000001CB7AAO"}
  mobile_phone_verified = false
  is_app_installed = true
  photos = {"picture":"https:\/\/c.ap1.content.force.com\/profilephoto\/005\/F","thumbnail":"https:\/\/c.ap1.content.force.com\/profilephoto\/005\/T"}
  display_name = varun ojha
  last_modified_date = 2013-06-04T07:43:42.000+0000
  email = **************
  addr_country = IN
  organization_id = 00D90000000mQaYEAU
  last_name = ojha
  utcOffset = -28800000
  active = true
  language = en_US
  addr_zip = 560071

Como se pode ver, é possível acessar com sucesso as informações da conta do proprietário do recurso de Salesforce realizando a autenticação usando OAuth 2.0. Depois de o token de acesso fornecido no arquivo de configuração expirar, o cliente gera novamente, de modo automático, o token de acesso na próxima solicitação e o utiliza para recuperar o recurso protegido disponível na URL do servidor de recurso.

Registrando-se com Google

O Google usa OAuth 2.0 para autenticar APIs que podem ser usadas para acessar serviços como GoogleDrive, TaskQueue e CloudSQL, para citar apenas alguns. É possível configurar um aplicativo para testar o cliente OAuth 2.0 com o Google seguindo as instruções em: https://developers.google.com/accounts/docs/OAuth2?hl=ES.

Executando o cliente com o Google

Agora que você configurou o servidor em conformidade com OAuth 2.0, está pronto para testar seu cliente e recuperar informações protegidas do servidor.

É possível encontrar o arquivo Oauth2Client_Google.config sob a pasta Java resources/src. Esse arquivo de configuração é customizado para uso com os serviços Google e pode ser usado como um modelo para fornecer valores de configuração.

Execute a atualização Aplicativo da web Oauth2Client no servidor Tomcat, como mostrado anteriormente. O fluxo e as saídas para o token Get Access e as operações de recursos protegidos contra acesso são mostrados em Figura 6.

Figura 6. Solicitação de token de acesso (prompt de login)
Access Token Request (Login Prompt)
Access Token Request (Login Prompt)

Figura 6 mostra a página de login do Google a qual o cliente redirecionou o agente do usuário (navegador da web) depois de 302 e o cabeçalho Location ter sido recebido do Google.

Figura 7 mostra o prompt de aprovação para o proprietário dos recursos (pós-login) para conceder acesso ao Cast Iron App, que está solicitando acesso aos dados do proprietário do recurso.

Figura 7. Solicitação do token de acesso (prompt de aprovação)
Cast Iron approval                     screen
Cast Iron approval screen

Depois de o proprietário do recurso conceder acesso ao cliente, o terminal do token responde com os tokens de acesso e atualização. Você deve ver uma saída na janela do console similar à mostrada em Lista 13.

Lista 13.
********** Response Received **********
  expires_in = 3600
  token_type = Bearer
  refresh_token = 1/TtCxaFlKMRsHeIlxrY-2ZJIO8DcRmQEiQ_2Wxw8
  access_token = ya29.ZQDpI-ahF6TMURwAAABqBu-2-U0_lUWfbwh053j3db3PzaNXV4k_k6fc_VT7uQ

Recuperando informações do usuário do servidor Google

Agora que você possui o token de acesso, é possível fazer uma solicitação para acessar as informações do GoogleDrive do proprietário do recurso, o que requer autenticação OAuth 2.0.

Atualize o arquivo Oauth2Client.confg com o token de acesso e preencha a propriedade url do servidor de recurso com a URL do servidor de recurso com a qual ela será testada. Irei substituí-la por https://www.googleapis.com/drive/v2/about, que é a URL de informações da conta do GoogleDrive.

Agora, atualize o projeto e execute-o no servidor Tomcat novamente. Clique em Start Test para acessar o recurso protegido.

Você deve ver uma saída na janela do console similar ao fragmento mostrado em Lista 14.

Lista 14.
********** Response Received **********
  name = Varun Ojha
  features = [{"featureName":"ocr"},{"featureName":"translation","featureRate":0.5}]
  quotaBytesTotal = 16106127360
  largestChangeId = 1911
  rootFolderId = 0ALupA2Opqyp1Uk9PVA
  quotaType = LIMITED
  quotaBytesByService = [{"bytesUsed":"229","serviceName":"DRIVE"},{"bytesUsed":"1154860956","serviceName":"GMAIL"},{"bytesUsed":"568174452","serviceName":"PHOTOS"}]
  permissionId = 01822620516456565194
  quotaBytesUsedInTrash = 119332

Como se pode ver, é possível acessar com sucesso as informações da conta do proprietário do recurso a partir de GoogleDrive realizando a autenticação usando OAuth 2.0.

Depois de o token de acesso fornecido no arquivo de configuração expirar, o cliente gerará novamente, de modo automático, o token de acesso na próxima solicitação e usará o token gerado para recuperar o recurso protegido disponível na URL do servidor de recurso.

Testando o cliente com terminais IBM

Esse código de amostra do cliente foi testado com sucesso com terminais IBM em conformidade com OAuth 2.0, como IBM Websphere® Application Server e IBM Datapower.®

Instruções para configurar um servidor OAuth 2.0 em um Websphere Application Server podem ser encontradas em "Usando OAuth: ativando o provedor de serviço OAuth no WebSphere Application Server."

Os terminais IBM podem ser testados da mesma maneira que se testa para Salesforce e Google.

Conclusão

A Parte 3 desta série de tutoriais explicou os fundamentos do tipo de concessão de código de autorização. Demonstrou como um cliente OAuth 2.0 genérico em código Java pode ser escrito para conectar-se a vários terminais em conformidade com OAuth 2.0 e recuperar os recursos protegidos deles. O projeto da web do cliente de amostra de Recursos para download pode ser importado para um ambiente do Eclipse e usado como um ponto de partida para criar um cliente Oauth 2.0 customizado.


Recursos para download


Temas relacionados


Comentários

Acesse ou registre-se para adicionar e acompanhar os comentários.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Tecnologia Java
ArticleID=995156
ArticleTitle=Clientes OAuth 2.0 em programação Java, Parte 3: concessão de código de autorização
publish-date=01162015