Skip to Main Content

ORDS, SODA & JSON in the Database

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

ORDS 18.3.0.r2701456 - security.oauth.tokenLifetime still leading to 41 day long token duration?

Erik RaetzOct 24 2018 — edited Jan 17 2019

*UPDATE* As of 2019-01-15 a bugfix is available by using ORDS 18.4. We tested ORDS 18.4 and can confirm that this bug has been fixed.

We reported a bug in august showing that the token duration was increased by a factor of 1000.

18.2.0.r1831332 - security.oauth.tokenLifetime value of 3600 increased by a factor of 1000 leading to tokens that last 41 days!

According to https://www.oracle.com/technetwork/developer-tools/rest-data-services/downloads/ords-relnotes-183-5100543.html

the bug should be fixed: BUG:28518849 - Fix regression that caused OAuth token lifetimes to 1000 times what they should be

We updated ORDS on our developer database to 18.3.0.r2701456 today.

When we register a token now with:

curl -X POST \

{ORDS_PATH}/oauth/token \

-H 'Authorization: Basic {OAUTH_CLIENT}' \

-H 'Cache-Control: no-cache' \

-H 'Content-Type: application/x-www-form-urlencoded' \

-d grant_type=client_credentials

ORDS responds with:

{

"access\_token": "{OAUTH\_TOKEN}",

"token\_type": "bearer",

"expires\_in": 3600

}

Tests showed that the registered tokens where still usable even after being used for more than one hour. We thought maybe tokens just refresh duration now and waited for over one hour before using that token again. Same issue. Token was still usable.

Here is our entry from the defaults.xml:

<entry key="security.oauth.tokenLifetime">3600</entry>

I will add a screenshot that shows what we see for those tokens in ords_metadata.sec_sessions. The screenshots show what we saw in the session table in june (before updating to 18.2 was 3.0.2 before) and what we see now in october (with 18.3).

sessions-june.png

sessions-october.png

The token duration was -1 before. Now we see two different token types.
The token that the oauth/token service delivers is of token type third_party now ans as you can see lists a token duration of 3600000 seconds which is 41 days and a bit.

Why are there two tokens and why does the REFRESH token has such a long duration? 86400000 would be 1000 days.

If it is of any help here is the content of the state clob: {"user":"WQXXXXXXXXXXXXXXGQ..","roles":["rolename","OAuth2 Client Application"],"partyType":"CLIENT_APPLICATION"}

Is there an issue with our configuration or is the token duration still bugged?

*edit* Maybe there is an issue with the oauth client auth flow?

---

From the docs:

Use the authorization code flow when you need to permit third party web applications

to access a RESTful API and the third party application has its own web server where

it can keep its client credentials secure. This is the typical situation for most web

applications, and it provides the most security and best user experience, because the

third party application can use refresh tokens to extend the life of a user session

without having to prompt the user to reauthorize the application.

Use the client credentials flow when you need to give a third party application direct

access to a RESTful API without requiring a user to approve access to the data

managed by the RESTful API. The third party application must be a server-based

application that can keep its credentials secret. The client credentials flow must not be

used with a native application, because the client credentials can always be

discovered in the native executable.

---

Here is an example of how the client was registered. We use client credential flow. Privileges are given to clients via roles.

oauth.create_client(p_name => 'oauth clientname', p_grant_type => 'client_credentials', p_privilege_names => NULL, p_support_email => 'email_address');

oauth.grant_client_role('oauth clientname', 'clientrole');

Thanks,

Erik

This post has been answered by Erik Raetz on Jan 17 2019
Jump to Answer
Comments
Post Details
Added on Oct 24 2018
8 comments
2,251 views