Oracle REST Data Services (ORDS) : Authentication 认证

OAuth : Client Credentials

The client credentials flow is a two-legged process that seems the

most natural to me as I mostly deal with server-server

communication, which should have no human interaction. For this

flow we use the client credentials to return an access token, which

is used to authorize calls to protected resources. The example

steps through the individual calls, but in reality it would be

automated by the application.

Remember to clean up the OAUTH metadata, as described in the

Deleting OAUTH Metadata section.

Create a client with the grant type of "client_credentials".

BEGIN

OAUTH.create_client(

p_name => 'emp_client',

p_grant_type => 'client_credentials',

p_owner => 'My Company Limited',

p_description => 'A client for Emp management',

p_support_email => 'tim@example.com',

p_privilege_names => 'emp_priv'

);

COMMIT;

END;

/

-- Display client details.

COLUMN name FORMAT A20

SELECT id, name, client_id, client_secret

FROM user_ords_clients;

ID

NAME CLIENT_ID CLIENT_SECRET

---------- -------------------- --------------------------------

--------------------------------

10316

emp_client 3NvJRo_a0UwGKx7Q-kivtA.. F5WVwyrWxXj3ykmhSONldQ..

SQL>

-- Display client-privilege relationship.

SELECT name, client_name

FROM user_ords_client_privileges;

NAME CLIENT_NAME

-------------------- ------------------------------

emp_priv emp_client

SQL>

Associate the client with the role that holds the correct

privileges for the resources it needs to access.

BEGIN

OAUTH.grant_client_role(

p_client_name => 'emp_client',

p_role_name =>

'emp_role'

);

COMMIT;

END;

/

-- Display client-role relationship.

COLUMN client_name FORMAT A30

COLUMN role_name FORMAT A20

SELECT client_name, role_name

FROM user_ords_client_roles;

CLIENT_NAME ROLE_NAME

------------------------------ --------------------

emp_client emp_role

SQL>

In order to access the web service, we must first retrieve an

access token using the CLIENT_ID and CLIENT_SECRET we queried from

the USER_ORDS_CLIENTS view.

CLIENT_ID : 3NvJRo_a0UwGKx7Q-kivtA..

CLIENT_SECRET : F5WVwyrWxXj3ykmhSONldQ..

OAUTH

URL : https://localhost:8443/ords/hr/oauth/token

The example below retrieves the access token. Notice the user

format of "CLIENT_ID:CLIENT_SECRET". It is easy to miss the ":"

when you look at this for the first time.

$ curl -i -k --user

3NvJRo_a0UwGKx7Q-kivtA..:F5WVwyrWxXj3ykmhSONldQ.. --data

"grant_type=client_credentials" https://localhost:8443/ords/hr/oauth/token

HTTP/1.1 200 OK

Server: Apache-Coyote/1.1

X-Frame-Options: SAMEORIGIN

Content-Type: application/json

Transfer-Encoding: chunked

Date: Wed, 29 Jun 2016 12:07:02 GMT

{"access_token":"-zYl-sFyB2iLicAHw2TsRA..","token_type":"bearer","expires_in":3600}

$

We can now use the access token to call our web service. Notice the

"Authorization: Bearer {access-token}" entry in the header of the

call.

$ curl -i -k -H"Authorization: Bearer -zYl-sFyB2iLicAHw2TsRA.."

https://localhost:8443/ords/hr/employees/7788

HTTP/1.1 200 OK

Server: Apache-Coyote/1.1

ETag:

"jtC17IXyetESUjSkxB2ani/a1TnFh28yfor+fLmxxUzGr6G9IFxQ77+/Gd71W4Qzz0rSxf90Qqbl+ICwezTayQ=="

Content-Type: application/json

Transfer-Encoding: chunked

Date: Wed, 29 Jun 2016 12:07:31 GMT

{"items":[{"empno":7788,"ename":"SCOTT","job":"ANALYST","mgr":7566,"hiredate":"1987-04-18T23:00:00Z","sal":3003,

"comm":null,"deptno":20}],"hasMore":false,"limit":0,"offset":0,"count":1,"links":[{"rel":"self",

"href":"https://localhost:8443/ords/hr/employees/7788"},{"rel":"describedby",

"href":"https://localhost:8443/ords/hr/metadata-catalog/employees/item"}]}

$

We successfully accessed the protected web service.

OAuth : Authorization Code

The authorization code flow is a three-legged process. The user

accesses a URL in a browser, which prompts for credentials. Once

authorized, the browser is redirected to a specified page with an

authhorization code as one of the parameters in the URL. That

authorization code is used in a call to generate an access token,

which is used to authorize calls to protected resources. With the

exception of the user confirmation, all the other steps in the flow

should be handled by the application. All the steps will be

presented separately in the example that follows.

This flow sounds complicated, but the important point to

remember is the calling application never sees the user

credentials. ORDS handles the user login and sends an authorization

code back to the application, so it can continue with the

authorization process.

Remember to clean up the OAUTH metadata, as described in the

Deleting OAUTH Metadata section. The first-party authentication

must be working for this flow to work.

Create a client using the grant type of "authorization_code".

The redirect and support URLs are not real, but we will be able to

follow the example through anyway.

BEGIN

OAUTH.create_client(

p_name => 'emp_client',

p_grant_type => 'authorization_code',

p_owner => 'My Company Limited',

p_description => 'A client for Emp management',

p_redirect_uri => 'https://localhost:8443/ords/hr/redirect',

p_support_email => 'tim@example.com',

p_support_uri => 'https://localhost:8443/ords/hr/support',

p_privilege_names => 'emp_priv'

);

COMMIT;

END;

/

-- Display client details.

COLUMN name FORMAT A20

SELECT id, name, client_id, client_secret

FROM user_ords_clients;

ID

NAME CLIENT_ID CLIENT_SECRET

---------- -------------------- --------------------------------

--------------------------------

10333

emp_client gxqNSyxPbLUJhSj1yBe8qA.. E-_mKJBlOTfTdHc_zISniA..

SQL>

We then attempt to request an authorization code. Notice we are

using the CLIENT_ID from the USER_ORDS_CLIENTS view along with a

unique string that will represent the state.

CLIENT_ID : gxqNSyxPbLUJhSj1yBe8qA..

State

https://localhost:8443/ords/hr/oauth/auth?response_type=code&client_id=gxqNSyxPbLUJhSj1yBe8qA..&state=3668D7A713E93372E0406A38A8C02171

You are presented with a 401 message, which includes a "sign in"

link. Click the link, sign in with the ORDS credentials you created

earlier (emp_user) and you will be directed to an approval page.

Click the "Approve" button, which will take you to the redirect

page you specified for the client.

The redirect page we specified for the client doesn't really

exist, but we can get the authorization code and state from the

URL.

https://localhost:8443/ords/hr/redirect?code=FF-APuIMukuBlrver1XU2A..&state=3668D7A713E93372E0406A38A8C02171

The application should check the state string matches the one used

in the initial call. We use the authorization code to retrieve the

access token.

CLIENT_ID : gxqNSyxPbLUJhSj1yBe8qA..

CLIENT_SECRET : E-_mKJBlOTfTdHc_zISniA..

User : CLIENT_ID:CLIENT_SECRET

Data : grant_type=authorization_code&code={authorization-code}

URL : https://localhost:8443/ords/hr/oauth/token

The following call retrieves the access token.

$ curl -i -k --user

gxqNSyxPbLUJhSj1yBe8qA..:E-_mKJBlOTfTdHc_zISniA.. --data

"grant_type=authorization_code&code=FF-APuIMukuBlrver1XU2A.."

https://localhost:8443/ords/hr/oauth/token

HTTP/1.1 200 OK

Server: Apache-Coyote/1.1

X-Frame-Options: SAMEORIGIN

Content-Type: application/json

Transfer-Encoding: chunked

Date: Wed, 29 Jun 2016 12:38:52 GMT

{"access_token":"cOYb2hFK_SyxOh8o9n6R7A..","token_type":"bearer","expires_in":3600,"refresh_token":"RC33rvSwAfhguraOWlvgfA.."}

$

We can now access the protected resource using the access

token.

$ curl -i -k -H"Authorization: Bearer cOYb2hFK_SyxOh8o9n6R7A.."

https://localhost:8443/ords/hr/employees/7788

HTTP/1.1 200 OK

Server: Apache-Coyote/1.1

ETag:

"jtC17IXyetESUjSkxB2ani/a1TnFh28yfor+fLmxxUzGr6G9IFxQ77+/Gd71W4Qzz0rSxf90Qqbl+ICwezTayQ=="

Content-Type: application/json

Transfer-Encoding: chunked

Date: Wed, 29 Jun 2016 12:40:34 GMT

{"items":[{"empno":7788,"ename":"SCOTT","job":"ANALYST","mgr":7566,"hiredate":"1987-04-18T23:00:00Z","sal":3003,

"comm":null,"deptno":20}],"hasMore":false,"limit":0,"offset":0,"count":1,"links":[{"rel":"self",

"href":"https://localhost:8443/ords/hr/employees/7788"},{"rel":"describedby",

"href":"https://localhost:8443/ords/hr/metadata-catalog/employees/item"}]}

$

As mentioned before, this looks complicated, but it allows a

calling application to authenticate to a web service without seeing

the user credentials. The application just has to know the

CLIENT_ID and SECRET that were registered for it, and go through

the user approval process to get the authorisation code.

OAuth : Implicit

The implicit flow is a two-legged process that requires user

interaction. The user accesses a URL in a browser, which prompts

for credentials. Once authorized, the browser is redirected to a

specified page with an access token as one of the parameters in the

URL. That access token is used to authorize calls to protected

resources. The example steps through the individual calls, but in

reality everything but the user interaction would be automated by

the application.

Remember to clean up the OAUTH metadata, as described in the

Deleting OAUTH Metadata section.

Create a client using the grant type of "implicit". The redirect

and support URLs are not real, but we will be able to follow the

example through anyway.

BEGIN

OAUTH.create_client(

p_name => 'emp_client',

p_grant_type => 'implicit',

p_owner => 'My Company Limited',

p_description => 'A client for Emp management',

p_redirect_uri => 'https://localhost:8443/ords/hr/redirect',

p_support_email => 'tim@example.com',

p_support_uri => 'https://localhost:8443/ords/hr/support',

p_privilege_names => 'emp_priv'

);

COMMIT;

END;

/

-- Display client details.

COLUMN name FORMAT A20

SELECT id, name, client_id, client_secret

FROM user_ords_clients;

ID

NAME CLIENT_ID CLIENT_SECRET

---------- -------------------- --------------------------------

--------------------------------

10325

emp_client 0docHbkL8__7Ic58n7GCBA..

SQL>

We then attempt to request an access token. Notice we are using the

CLIENT_ID from the USER_ORDS_CLIENTS view along with a unique

string that will represent the state.

CLIENT_ID : 0docHbkL8__7Ic58n7GCBA..

State

https://localhost:8443/ords/hr/oauth/auth?response_type=token&client_id=0docHbkL8__7Ic58n7GCBA..&state=3668D7A713E93372E0406A38A8C02171

You are presented with a 401 message, which includes a "sign in"

link. Click the link, sign in with the ORDS credentials you created

earlier (emp_user) and you will be directed to an approval page.

Click the "Approve" button, which will take you to the redirect

page you specified for the client.

The redirect page we specified for the client doesn't really

exist, but we can get the access token from the URL.

https://localhost:8443/ords/hr/redirect#token_type=bearer&access_token=5SVR_NVP5N_OnDQt6iSxJg..&expires_in=3600&state=3668D7A713E93372E0406A38A8C02171

The application should check the state string matches the one used

in the initial call. We can now access the protected resource using

the access token.

$ curl -i -k -H"Authorization: Bearer 5SVR_NVP5N_OnDQt6iSxJg.."

https://localhost:8443/ords/hr/employees/7788

HTTP/1.1 200 OK

Server: Apache-Coyote/1.1

ETag:

"jtC17IXyetESUjSkxB2ani/a1TnFh28yfor+fLmxxUzGr6G9IFxQ77+/Gd71W4Qzz0rSxf90Qqbl+ICwezTayQ=="

Content-Type: application/json

Transfer-Encoding: chunked

Date: Wed, 29 Jun 2016 12:15:35 GMT

{"items":[{"empno":7788,"ename":"SCOTT","job":"ANALYST","mgr":7566,"hiredate":"1987-04-18T23:00:00Z","sal":3003,

"comm":null,"deptno":20}],"hasMore":false,"limit":0,"offset":0,"count":1,"links":[{"rel":"self",

"href":"https://localhost:8443/ords/hr/employees/7788"},{"rel":"describedby",

"href":"https://localhost:8443/ords/hr/metadata-catalog/employees/item"}]}

$

-- 刘轶鹤转

内容来自网络