aditya-t
6/29/2017 - 2:25 AM
sso-api-swagger.json
{
"swagger": "2.0",
"info": {
"title": "OKAPI SSO API",
"description": "OKAPI SSO will allow applications to integrate with Telstra's identity systems via modern open standards in order to:\n- authenticate users via OpenID Connect, \n- query basic user profile information; and \n- obtain OAuth tokens authorising API calls in the context of the authenticated user. \n\nA range of different client application types will be supported including JavaScript-based single page applications, traditional web applications and native mobile apps.",
"version": "1.0",
"termsOfService": "https://dev.telstra.com/legal",
"license": {
"name": "Apache 2.0",
"url": "http://www.apache.org/licenses/LICENSE-2.0.html"
}
},
"host": "api.telstra.com",
"schemes": [
"https"
],
"basePath": "/v1/sso",
"paths": {
"/auth": {
"get": {
"operationId": "authOperation",
"summary": "Get authorization from the end user",
"description": "The authorization endpoint performs authentication of the user, redirecting users to the IDP (e.g. RAA) as required. It is also useful for validating the current authentication status of the user.",
"produces": [
"application/json"
],
"parameters": [
{
"name": "response_type",
"in": "query",
"required": true,
"description": "Supported values:\n\n\"id_token token\" or just \"id_token\" (implicit flow)\n\n\"code\" (authorization code flow).",
"type": "string"
},
{
"name": "client_id",
"in": "query",
"description": "Uniquely identifies the client application. \n\nThis is the Consumer Key registered in the OKAPI developer portal.\n",
"required": true,
"type": "string"
},
{
"name": "redirect_uri",
"in": "query",
"description": "Client callback endpoint to which the response will be sent.\n",
"required": true,
"type": "string"
},
{
"name": "scope",
"in": "query",
"required": false,
"description": "Space separated list of scope values, which must include the value \"openid\" for clients using the implicit grant flow. Refer to the authorization model for details of the other available scopes.\n\nFor clients using the authorization code flow, this parameter is optional and non-inclusion is equivalent to requesting the maximum number of scopes the client is authorised to request.\n",
"type": "string"
},
{
"name": "state",
"in": "query",
"description": "Opaque value used to transfer state between the request and the callback.\n\nRefer to OpenID.Core for further details on the appropriate use of this parameter.\n",
"required": false,
"type": "string"
},
{
"name": "nonce",
"in": "query",
"description": "A cryptographically random value generated by the client and used to mitigate against replay attacks.\n\nRequired for clients using the implicit grant flow.\n\nRefer to OpenID.Core for further details on the appropriate use of this parameter.\n",
"required": false,
"type": "string"
},
{
"name": "prompt",
"in": "query",
"description": "Set to \"none\" to validate the current session without prompting for user interaction.\n\nIf not provided, the user will be prompted to login only as required by the IDP, for example if they don't have a current login session.\n\n(A prompt value of \"login\" is also accepted but will be ignored).\n",
"required": false,
"type": "string"
},
{
"name": "max_age",
"in": "query",
"description": "May be included in the request, but will not have any effect on the whether a user is asked to reauthenticate.\n\nIf this parameter is included then the auth_time claim will be included in the ID token.\n",
"required": false,
"type": "string"
},
{
"name": "id_token_hint",
"in": "query",
"description": "A previously issued ID token indicating the user's current or past authenticated session with the client.\n\nThis parameter should be passed when revalidating or refreshing an existing session to ensure that the current session is for the same user.\n",
"required": false,
"type": "string"
}
],
"tags": [
"Auth"
],
"responses": {
"302": {
"description": "After the authentication process is complete, a 302 redirect is issued back to the url specified in the redirect_uri parameter in the original authorize request.\n\n---\nImplicit Flow Successful Scenario:\n\nThe successful response is delivered via a redirect, with the response parameters included in the fragment component of the redirection URI, for example:\n\n HTTP/1.1 302 Found\n Location: https://api./sampleshop/cb#access_token=AtE5t4WRgfT8lR71GiDyaRkd&token_type=Bearer&id_token=I8aK8Dk5j...iD3ls48Dsk&expires_in=870&state=afdfjldgm\n \nThe id_token and access_token should be validated as set out in OpenID.Core.\n\nThe following response parameters may be returned:\n- id_token \n Included: Optional\n Description: An ID token (JWT) is returned if the response_type includes \"id_token\"\n- access_token \n Included: Optional\n Description: An access token is returned if the response_type includes \"token\".\n- token_type\n Included: Optional\n Description: The type of the access token (\"Bearer\") if one was returned.\n- scope\n Included: Optional\n Description: The scope represented by the access token if different to that which was requested.\n- expires_in\n Included: Optional\n Description: The expiry time of the access token if one was returned.\n- state\n Included: Optional\n Description: Returned if provided in the request.\n---\nImplicit Flow Failure Scenario:\n\nError conditions are signalled via the error parameter in the fragment component of the redirection response (along with the state parameter if provided). The exception is where the redirect URI cannot be validated, in which case the error response is returned directly. \n\nIn the following example, the error is delivered via a redirect response, and so the error details are provided in the fragment component of the redirection URI:\n\n HTTP/1.1 302 Found\n Location: https: //www.telstra.com.au/sampleshop/cb#error=login_required&state=xyz\n\nBy contrast, in this example the error response is delivered directly because the redirect URI could not be validated:\n\n HTTP/1.1 400 Bad Request\n Content-Type: application/json\n \n {\n \"error\":\"invalid_request\"\n \"error_description\":\"Missing parameter: client_id\"\n }\n\nError Parameters:\n\n- invalid_request\n Invalid request excluding the client_id and redirect_uri parameters; or includes cases of missing parameters.\n- unsupported_response_type\n The specified response_type does not match one of the values registered in client metadata.\n- invalid_scope\n The openid scope which is mandatory for the implicit flow was not included in the request.\n- login_required\n No current web session, but user cannot be prompted to log in because prompt=none.\n- access_denied\n The user declined to authenticate or their authentication attempt failed.\n- server_error\n An unexpected error occurred while processing the request (equivalent to a 500 Internal Server Error).\n- temporarily_unavailable\n The request was throttled (equivalent to 503 Service Unavailable). \n\n---\nAuthorization Code Flow Successful Scenario:\n\nThe successful response is delivered via a redirect, with the response parameters included as query component of the redirection URI, for example:\n\n HTTP/1.1 302 Found\n Location: https://api./sampleshop/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=afdfjldgm\n\nThe following response parameters may be returned:\n- code \n Included: Optional\n Description: An authorization code is included if the response_type is \"code\"\n- state\n Included: Optional\n Description: Returned if provided in the request.\n---\nAuthorization Code Flow Failure Scenario:\n\nError conditions are signalled via the error parameter in the query component of the redirection response (along with the state parameter if provided). The exception is where the redirect URI cannot be validated, in which case the error response is returned directly. \n\nIn the following example, the error is delivered via a redirect response, and so the error details are provided in the query component of the redirection URI:\n\n HTTP/1.1 302 Found\n Location: https: //www.telstra.com.au/sampleshop/cb?error=login_required&state=xyz\n\nBy contrast, in this example the error response is delivered directly because the redirect URI could not be validated:\n\n HTTP/1.1 400 Bad Request\n Content-Type: application/json\n \n {\n \"error\":\"invalid_request\"\n \"error_description\":\"Missing parameter: client_id\"\n }\n\nError Parameters:\n\n- invalid_request\n Invalid request excluding the client_id and redirect_uri parameters; or includes cases of missing parameters.\n- unsupported_response_type\n The specified response_type does not match one of the values registered in client metadata.\n- access_denied\n The user declined to authenticate or their authentication attempt failed.\n- server_error\n An unexpected error occurred while processing the request (equivalent to a 500 Internal Server Error).\n- temporarily_unavailable\n The request was throttled (equivalent to 503 Service Unavailable). \n- invalid_scope\n All requested scopes were invalid."
},
"400": {
"description": "- invalid_request\n Invalid request where the client_id or redirect_uri cannot be determined; or includes cases of missing parameters or a redirect_uri mismatch.\n"
},
"403": {
"description": "- invalid_client\n Unregistered client.\n"
}
}
}
},
"/logout": {
"get": {
"operationId": "logoutOperation",
"summary": "Logout from SSO",
"description": "The logout or end-session endpoint supports RP-initiated single logout. It allows single page applications to indicate that the user has logged out of that application. As these applications share the common Telstra login session, this will also result in their RAA web session being terminated and cookies cleared.\n\nLogout behaviour - When the OKAPI SSO OP receives a logout request from a client application, it will perform the following actions:\n- Validate the ID token (ignoring expiry).\n- If the ID token is valid, look up the client's current access token (i.e. the one that was originally issued alongside the ID token) using the at_hash and revoke it.\n- Redirect to RAA to terminate the web session and clear cookies across all three domains, after which RAA will redirect back again.\n- If the ID token is valid and a valid post-logout redirect URI was provided, redirect the browser to that URI. Otherwise, redirect to the default URI.\n\nStandards:\n- The end-session endpoint is described in the OpenID Connect Session Management specification [OpenID.Session].\n",
"produces": [
"application/json"
],
"parameters": [
{
"name": "id_token_hint",
"description": "Previously issued ID token, possibly expired.",
"in": "query",
"required": true,
"type": "string"
},
{
"name": "post_logout_redirect_uri",
"description": "Redirect the user back to the client application after the logout has been performed. Validated against client metadata.",
"in": "query",
"required": false,
"type": "string"
},
{
"name": "state",
"description": "Value to be passed back to the client application in the post-logout redirect response.",
"in": "query",
"required": false,
"type": "string"
}
],
"tags": [
"Logout"
],
"responses": {
"200": {
"description": "If a valid (ignoring expiry) id_token_hint and a corresponding post_logout_redirect_uri parameter were included in the request, then the browser will be redirected to the given URI, echoing the state query parameter if one was supplied:\n\n HTTP/1.1 302 Found\n Location: https://www.telstra.com.au/sampleshop?state=xyz\n\nOtherwise, the browser will be redirected to a default page (www.telstra.com.au) without the state parameter:\n\n HTTP/1.1 302 Found\n Location: https://www.telstra.com.au\n"
}
}
}
},
"/token": {
"post": {
"operationId": "tokenOperation",
"summary": "Get access token",
"description": "The token endpoint provides the means by which non-JavaScript clients obtain access tokens, refresh tokens and ID tokens. \n\nNote:\n- Rate limiting and/or other measures are to be put in place.\n- CORS is not supported.\n- JavaScript-based applications should obtain tokens from the authorization endpoint instead, i.e. using the implicit grant flow.\n\nSupported grant types:\n\n - raa_token\n Description: RAA Token\n Supported on endpoints: Token (external and internal)\n For application types: Specially approved mobile apps using active authentication against RAA\n \n - refresh_token\n Description: Refresh Token\n Supported on endpoints: Token (external)\n For application types: Mobile apps, traditional web applications, specially approved mobile apps\n using active authentication against RAA\n \n - authorization_code\n Description: Authorization Code\n Supported on endpoints: Token (external)\n For application types: Applications which require long-lived access and can guarantee the\n confidentiality of their client_secret\n \n - urn:ietf:params:oauth:grant-type:saml2-bearer\n Description: SAML Assertion\n Supported on endpoints: Token (external)\n For application types: Web applications using Fides (SecureAuth) to authenticate staff users\n \nThe following example shows a request using the Refresh Token grant type:\n \n POST /v1/sso/token HTTP/1.1\n Host: api.telstra.com\n Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW\n Content-Type: application/x-www-form-urlencoded\n \n grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA\n",
"consumes": [
"application/x-www-form-urlencoded"
],
"produces": [
"application/json"
],
"security": [
{
"basicAuth": []
}
],
"parameters": [
{
"name": "grant_type",
"in": "formData",
"description": "Valid values are \"authorization_code\", \"raa_token\", \"refresh_token\" or \"urn:ietf:params:oauth:grant-type:saml2-bearer\"\n\nGrant type applicability: All\n",
"required": true,
"type": "string"
},
{
"name": "refresh_token",
"in": "formData",
"description": "The refresh token to be exchanged\n\nGrant type applicability: refresh_token\n",
"required": false,
"type": "string"
},
{
"name": "raa_token",
"in": "formData",
"description": "A RAA token obtained from the RAA authenticate API by a specially approved mobile app.\n\nTwo types of RAA tokens are accepted.\n- Normal session tokens, which are exchangeable for access tokens only.\n- Short-lived \"auth-only\" tokens, which are exchangeable for refresh tokens and access tokens \n\nGrant type applicability: raa_token\n",
"required": false,
"type": "string"
},
{
"name": "scope",
"in": "formData",
"description": "Scopes for the requested token.\n\nGrant type applicability: raa_token, refresh_token, urn:ietf:params:oauth:grant-type:saml2-bearer\n",
"required": false,
"type": "string"
},
{
"name": "assertion",
"in": "formData",
"description": "A SAML assertion obtained from a trusted issuer (currently only Fides).\n\nGrant type applicability: urn:ietf:params:oauth:grant-type:saml2-bearer\n",
"required": false,
"type": "string"
},
{
"name": "code",
"in": "formData",
"description": "The authorization code obtained from a successful request to the authorization endpoint using the \"code\" response type.\n\nGrant type applicability: authorization_code\n",
"required": false,
"type": "string"
},
{
"name": "redirect_uri",
"in": "formData",
"description": "The client's pre-registered callback URL.\n\nGrant type applicability: authorization_code\n",
"required": false,
"type": "string"
}
],
"tags": [
"Token"
],
"responses": {
"200": {
"description": "The following response parameters may be returned:\n\n- access_token\n Grant type applicability: All\n Notes: New access token.\n \n- token_type\n Grant type applicability: All\n Notes: Always \"Bearer\" in this implementation.\n \n- expires_in\n Grant type applicability: All\n Notes: Expiry of the new access token, as per the access_token_lifetime client metadata parameter.\n \n- refresh_token\n Grant type applicability: raa_token, refresh_token, authorization_code\n Notes: New refresh token if applicable, i.e. the client metadata parameter grant_types includes \"refresh_token\" and refresh_token_lifetime is non-zero. \n In the case of the Refresh Token grant type, the issuing of new refresh tokens is subject to the cycle_refresh_tokens client metadata parameter.\n \n- id_token\n Grant type applicability: raa_token, refresh_token\n \n- scope\n Grant type applicability: All\n Notes: The scope represented by the access token if different to that which was requested, otherwise omitted.\n \n The following example shows a response for the Refresh Token grant type:\n \n Note that the older Pragma:no-cache header shown below is probably not required, but is included in responses containing tokens as mandated by the OAuth 2.0 specifications.\n \n HTTP/1.1 200 OK\n Content-Type: application/json\n Cache-Control: no-store\n Pragma: no-cache\n {\n \"access_token\": \"R7AE22bjvGHS22YkE5QVIB6gYS32\",\n \"token_type\": \"Bearer\",\n \"refresh_token\": \"r5hjTK5Fo58Fdlw9kr94zkKekdm\",\n \"expires_in\": 3600\n }\n"
},
"400": {
"description": "Error conditions are signified by the HTTP status code and an error parameter.\n- invalid_request\n Grant type applicability: All\n Scenario: Malformed request\n- invalid_grant\n Grant type applicability: All\n Scenario: The authorization grant is invalid \n + For the RAA Token grant type:\n - The RAA token is invalid or expired\n - The RAA token is not an authentication-only token (i.e. realm=\"okapi\").\n + For the Refresh Token grant type:\n - The refresh token presented is invalid, expired or was issued to another client\n - The user account on whose behalf the refresh token was issued is not longer valid\n + For the Authorization Code grant type:\n - The authorization code presented is invalid, expired or was issued to another client\n - The redirection URI specified does not match the value included in the authorization request\n- unauthorized_client\n Grant type applicability: All\n Scenario: The client is not authorized to use this grant type, as per client metadata\n- unsupported_grant_type\n Grant type applicability: All\n Scenario: An unsupported grant type was specified\n- invalid_scope\n Grant type applicability: All\n Scenario: The requested scope is invalid or exceeds the preauthorised scope.\n Note that this never occurs in practice as unrecognised are ignored.\n"
},
"401": {
"description": "Error conditions are signified by the HTTP status code and an error parameter.\n- invalid_client\n Grant type applicability: All\n Scenario: Client authentication failed.\n"
}
}
}
},
"/globalflush": {
"post": {
"operationId": "globalFlushOperation",
"summary": "Revoke all access and refresh tokens associated with a user",
"description": "The global flush endpoint provides the means by which the identity provider (RAA) can initiate a revocation of all current access and refresh tokens associated with a user. This is done on behalf of the user via a password change or account termination event. \n\nNote:\n- This is a restricted endpoint which only listens on MASSL connections from privileged clients such as RAA.\n- This endpoint is currently only internet-accessible as firewall burns between RAA and OKAPI have not been confirmed.\n \nAn example global flush request:\n \n POST /v1/sso/globalflush HTTP/1.1\n Host: api.telstra.com\n Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW\n Content-Type: application/x-www-form-urlencoded\n \n end_user=G02000056589\n",
"consumes": [
"application/x-www-form-urlencoded"
],
"produces": [
"application/json"
],
"security": [
{
"basicAuth": []
}
],
"parameters": [
{
"name": "end_user",
"in": "formData",
"description": "A Telstra Digital Identity GUID.",
"required": true,
"type": "string"
}
],
"tags": [
"Global Flush"
],
"responses": {
"200": {
"description": "If the tokens were revoked successfully or there were no tokens to revoke then a success response (200) will be returned.\n"
},
"400": {
"description": "invalid_request\n Malformed request.\n"
},
"401": {
"description": "invalid_client\n Client authentication failed.\n"
}
}
}
},
"/revoke": {
"post": {
"operationId": "revokeOperation",
"summary": "Revoke access token and refresh token",
"description": "The token revocation endpoint provides the means by which clients can revoke access tokens and refresh tokens previously issued to them. It implements the OAuth 2.0 Token Revocation specification (OAuth.Revocation).\n\nThe primary use case in this release is mobile apps revoking the refresh token during a \"logout\" procedure.\n\nTo revoke a token, the client POSTs it along with an optional token type hint to the revocation endpoint. \n\nRevoking a refresh token also revokes any associated access tokens.\n\nAn example token revocation request:\n\n POST /v1/sso/revoke HTTP/1.1\n Host: api.telstra.com\n Content-Type: application/x-www-form-urlencoded\n Authorization: Basic dzZCaGRZa3F0MzpnMDdmQmF0M2JW\n\n token=H5ghiukldjaFDhdhFhhzdauz&token_type_hint=refresh_token\n \n",
"consumes": [
"application/x-www-form-urlencoded"
],
"produces": [
"application/json"
],
"security": [
{
"basicAuth": []
}
],
"parameters": [
{
"name": "Authorization",
"in": "header",
"description": "Authorization header in the format 'Bearer {access_token}'. Uses the\naccess token obtained from the /token endpoint.\n",
"type": "string",
"required": true
},
{
"name": "token",
"in": "formData",
"description": "The token to be revoked\n",
"type": "string",
"required": true
},
{
"name": "token_type_hint",
"in": "formData",
"description": "A hint about the type of the token - either refresh_token or access_token.\n\nNote that this parameter is for optimisation purposes only and does not have any functional impact.\n",
"type": "string",
"required": false
}
],
"tags": [
"Revoke"
],
"responses": {
"200": {
"description": "If the token was revoked successfully or the token was invalid then a success response (200) will be returned. \n"
},
"400": {
"description": "- invalid_request\n Malformed request\n- unauthorized_client\n The authenticated client is not authorised to present this token (i.e. it was issued to a different client application)\nAn example error response:\n\n HTTP/1.1 400 Bad Request\n Content-Type: application/json\n Cache-Control: no-store\n \n {\n \"error\":\"invalid_request\"\n }\n"
},
"401": {
"description": "- invalid_client\n Client authentication failed.\n\n"
}
}
}
},
"/userinfo": {
"get": {
"operationId": "userinfoOperation",
"summary": "Get user information.",
"description": "User profile claims provide information about the authenticated user to client applications. These claims are made available to authorised client applications from the UserInfo endpoint. User session should exist and valid in client's browser cookie before this operation.\n\nFor supported User Profile Claims please refer to:\n\nhttps://wiki.ae.sda.corp.telstra.com/display/ID/OKAPI+SSO+User+Profile+Claims\n",
"produces": [
"application/json"
],
"parameters": [
{
"name": "Authorization",
"in": "header",
"description": "Authorization header in the format 'Bearer {access_token}'. Uses the\naccess token obtained from the /token endpoint.\n",
"type": "string",
"required": true
}
],
"tags": [
"Userinfo"
],
"responses": {
"200": {
"description": "A successful response will contain the requested claims, subject to their availability and the client having been preauthorised to access them. Claims that cannot be returned for either of these reasons will be omitted from the response.\n\nExample response for a TDI user:\n \n HTTP/1.1 200 OK\n Content-Type: application/json\n \n {\n \"sub\": \"sK4QkRTM0tvFcU96fjsQXX26BSGSGtWLNcjEfNGQgeE\",\n \"name\": \"Jane Doe\",\n \"given_name\": \"Jane\",\n \"email\": \"janedoe@example.com\",\n \"tdi_guid\": \"G12340981203481\",\n \"tdi_ouid\": \"janedoe@bigpond.com\"\n \"tdi_ouid_verified\": true\n }\n \nExample for a staff user:\n\n HTTP/1.1 200 OK\n Content-Type: application/json\n \n {\n \"sub\": \"sI3QkRTN5tvFcU86fjsQyX26BSGSGtWLPcjEfNkQgrE\",\n \"name\": \"Jane Doe\",\n \"given_name\": \"Jane\",\n \"email\": \"jane.doe@team.telstra.com\",\n \"staff_userid\": \"d399999\",\n \"staff_roles\": [ \"Admin\" ]\n }\n"
},
"400": {
"description": "Error conditions are signified by the HTTP status code and an error parameter:\n\n- invalid_request\n Malformed request\n \n Example:\n\n HTTP/1.1 400 Bad Request\n Content-Type: application/json\n Cache-Control: no-store\n \n {\n \"error\":\"invalid_request\"\n \"error_description\":\"The request was malformed\"\n }\n"
},
"401": {
"description": "Error conditions are signified by the HTTP status code and an error parameter:\n\n- invalid_token\n The presented token was invalid or was not accompanied by the expected web session cookie.\n In this case a WWW-Authenticate response header field will also be included in the response.\n- N/A\n No token was presented with the request.\n In this case a WWW-Authenticate response header field will also be included in the response.\n"
},
"403": {
"description": "Error conditions are signified by the HTTP status code and an error parameter:\n\n- insufficient_scope\n The token does not permit access to this endpoint.\n \n"
}
}
}
},
"/keys": {
"get": {
"operationId": "keysOperation",
"summary": "Get keys.",
"description": "Clients obtain the current key set by making an unauthenticated GET request to the keys endpoint.\n\nNote: there is no parameters required for this operation. The JWKS document format is defined by the JSON Web Key [JWK] specification.\n\nExample request for keys endpoint:\n\n GET /v1/sso/keys HTTP/1.1\n Host: api.telstra.com\n",
"produces": [
"application/json"
],
"tags": [
"Keys"
],
"responses": {
"200": {
"description": "The response contains the JWKS document, along with a Cache-Control header indicating the maximum time that it should be cached.\n\nExample request for keys endpoint:\n \n HTTP/1.1 200 OK\n Cache-Control: max-age=86400\n Content-Type: application/jwk-set+json\n \n {\n \"keys\": [\n {\n \"kty\": \"RSA\",\n \"alg\": \"RS256\",\n \"use\": \"sig\",\n \"kid\": \"95kllfd95kf9rklghjl4s4359056c80665787754\",\n \"n\": \"afl178hd8asdjhjsdfjhff8jkdfkasfdasdf...afdlkrioasdfkljsdfkljsdfkljsdfa\",\n \"e\": \"AQAB\"\n },\n {\n \"kty\": \"RSA\",\n \"alg\": \"RS256\",\n \"use\": \"sig\",\n \"kid\": \"kdlgfedid8dkdl48ddkdfjlkd90dlldfkhkdf984\",\n \"n\": \"ahjdfsa7845hjjdsfjksdfhjfkdfu4257985...sadfkljasdfjklsadfkljsdflkasfaf\",\n \"e\": \"AQAB\"\n }\n ]\n }\n"
}
}
}
}
},
"securityDefinitions": {
"basicAuth": {
"type": "basic",
"description": "Use your app's consumer credentials for basic authentication. i.e. use your Consumer Key as the username and Consumer Secret as the password."
}
}
}