Methods of store.go are not being used about fosite

[aeneasr]

I agree that short lifetime is good for security but it will also incur much load on authorization server as it has to process frequent refresh requests. We could have clients from different platforms (JS based web app, android app, native desktop app etc.) with different usage and trust level. Say we have our own multiple apps or the apps from our trusted vendors with higher trust level, here it will be safe to issue tokens with longer expiry.

I am sorry but I have to disagree. The trust level should not be responsible for deciding token lifespan. Tokens can be stolen from trusted clients and untrusted clients alike. Keeping token lifetime short increases security. Please remember that OAuth2 is a delegation protocol and it should be treated as such. :)

Please read the official recommendation IETF RFC6819:

A short expiration time for tokens is a means of protection against
the following threats:
o replay
o token leak (a short expiration time will reduce impact)
o online guessing (a short expiration time will reduce the
likelihood of success)

Additionally, generating hmac tokens is cheap with fosite. The database might get some load but I don't think that it's going to be a real issue, even if token expiry is only an hour.

If we save/load expiry from database then it will give us ultimate control. You may have hundres of clients and each client has thousands of end users, consuming your API. Some day suddenly you found that a few clients are abusing or sending too many request. Here if you have expiry in database then you can easily expire there access token as well as refresh token so they have to authenticate again.

That is what token revokation(IETF RFC7009) is for. It's currently not implemented in hydra but it should be very easy to add an endpoint and remove malicious / leaked tokens from the database.

Another point I want to make is that issuing access token is not the bottleneck, but token lookup is. You are suggesting that the expiry time should be flexible. This does not work if you issue JWT, because you can't change their expiry values once the JWT is issued. If you want expiry time to be flexible, you will need to look up the token in the database every time you want to validate it. This will cause you real trouble ;)

If you fear that database load might be an issue, take a look at the Hydra Refactor. It's an authorization server that uses fosite and does everything in-memory.

Feel free to ask questions if things are unclear.

[aeneasr]

Hey, the methods in store.go are being called, I can guarantee that. Otherwise the example would not work.

[aeneasr]

Maybe you could show me what you tried to do :)

[samtech09]

I only added log.Println(...) statement at the begining of each method like this one

func (s *Store) GetClient(id string) (fosite.Client, error) {
    log.Println("Store.GetClient  executed...")
    cl, ok := s.Clients[id]
    if !ok {
        return nil, pkg.ErrNotFound
    }
    return cl, nil
}

After that i run the example

[samtech@M4800 server]$ go run main.go 
Please open your webbrowser at http://localhost:3846

Then i tried Authorize Code Grant, Resource owner password credentials grant etc. but i didn't see any log trace in console.

[aeneasr]

I can not reproduce this. I get:

D:\workspace\go\src\github.com\ory-am\fosite\fosite-example>go run main.go
Please open your webbrowser at http://localhost:3846
2016/05/16 11:28:58 Store.GetClient  executed...
2016/05/16 11:29:01 Store.GetClient  executed...
2016/05/16 11:29:01 Store.GetClient  executed...

after clicking on "authorize code grant" and logging in.

[samtech09]

After looking the output you shared, i deleted all old stuff, again did a fresh "go get github.com/ory-am/fosite", followed by glide update, then added log.Println(...) to GetClient() method

And now it is giving traces :)
I really do not know what was the problem.
Anyways, sorry for killing your time.
Now i will try to create store for postgresql database.

[aeneasr]

Don't worry, glad I was able to help!

[aeneasr]

If you need further assistance let me know

[samtech09]

Hi,

I have few queries, should i ask here or create new Issue (BTW those of
queries not the issue).

Please suggest.

On 05/16/16 22:11, Aeneas wrote:

If you need further assistance let me know

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#45 (comment)

Thanks & Regards
Sam Tech

[aeneasr]

Feel free to ask here. There is also a reference storage implementation usign rethinkdb here: https://github.com/ory-am/hydra/blob/refactor/internal/fosite_store_rethinkdb.go

[samtech09]

I am trying to implement client with following fields

type AppClient struct {

ID string json:"id"
AppName string json:"app_name"
Secret []byte json:"secret,omitempty"
RedirectURIs []string json:"redirect_uris"
GrantTypes []string json:"grant_types"
ResponseTypes []string json:"response_types"
Owner string json:"owner"
AccessTokenLife int json:"accesstoken_lifetime"
RefreshTokenLife int json:"refreshtoken_lifetime"
}

As you can see i have AccessTokenLife and RefreshTokenLife fields.
The task it is assign different expiry of AccessToken / RefreshToken per
client basis, depending on application type and usage.

For example Client-A may have AcessTokenLife of 30 min. and RefreshToken
life of 120 minutes.
And Client-B may have AcessTokenLife of 90 min. and RefreshToken life of
300 minutes.

I guess it is to be set in CreateAuthorizeCodeSession and similar
methods.
But fosite.Requester doesn't provide any method for that. For this we
need to save and later load expiry from database when requested by
fosite, so fosite can validate expiry.

Can you please suggest, how to achieve it.

On 05/28/16 13:52, Aeneas wrote:

Feel free to ask here. There is also a reference storage
implementation usign rethinkdb here:
https://github.com/ory-am/hydra/blob/refactor/internal/fosite_store_rethinkdb.go

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#45 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AKD0TRDM6QzJ5g2fmtc2co1GmZab_n6nks5qF_tggaJpZM4Ie4zk.

Thanks & Regards
Sam Tech

[aeneasr]

I see, currently fosite only supports a global access token life time: https://github.com/ory-am/fosite/blob/master/handler/core/explicit/explicit_auth.go#L31

It is validated for example here: https://github.com/ory-am/fosite/blob/master/handler/core/explicit/explicit_token.go#L66

A per request lifetime is not implemented right now but it seems like a common problem as this has been asked before. Can you maybe tell me why you need it exactly? Usually Access Tokens should have short lifetimes and be refreshed using Refresh Tokens which is why I didn't include per-client or per-request lifetimes.

[samtech09]

It will add more flexibility. Let me try to explain :)

Advantage of flexible lifetime

I agree that short lifetime is good for security but it will also incur
much load on authorization server as it has to process frequent refresh
requests.

We could have clients from different platforms (JS based web app,
android app, native desktop app etc.) with different usage and trust level.

Say we have our own multiple apps or the apps from our trusted vendors
with higher trust level, here it will be safe to issue tokens with
longer expiry.

But on the other side, for other 3rd party apps where trust level is
low, we should issue tokens with short lifespan.

Advantage of save/load expiry from database

If we save/load expiry from database then it will give us ultimate control.

You may have hundres of clients and each client has thousands of end
users, consuming your API. Some day suddenly you found that a few
clients are abusing or sending too many request.

Here if you have expiry in database then you can easily expire there
access token as well as refresh token so they have to authenticate again.

I am also planning to add support to enable/disable client so before
authorization it should check whether the client is active.

On Saturday 28 May 2016 07:44 PM, Aeneas wrote:

I see, currently fosite only supports a global access token life time:
https://github.com/ory-am/fosite/blob/master/handler/core/explicit/explicit_auth.go#L31

It is validated for example here:
https://github.com/ory-am/fosite/blob/master/handler/core/explicit/explicit_token.go#L66

A per request lifetime is not implemented right now but it seems like
a common problem as this has been asked before. Can you maybe tell me
why you need it exactly? Usually Access Tokens should have short
lifetimes and be refreshed using Refresh Tokens.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#45 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AKD0TQXTVtUImsCpyUijChkKz6szRzfAks5qGE2tgaJpZM4Ie4zk.

Thanks & Regards
Sam Tech

[aeneasr]

If you need help with implementing a Token Revokation endpoint let me know!

[samtech09]

Hmm.... your point is valid that with JWT we will not be able to expire
them. But that's not a big issue as custom hooks can be implemented in
resource server for that.

But still having flexibility to get/set expiry will be a great feature
for fosite. It is the only thing that i see as bootelneck in fosite. As
we are issuing tokens but we do not have control over it.

Approx 2 year ago i implemented oAuth2 server in C# using OSIN libraries
and using HMAC tokens.
There we implemented that feature and we were very happy wth that. We
also face few instances where few clients were poorly designed and not
comsuming API as it should be, so we just expire theire token and even
disabled few clients.

Not sure but i guess OSIN https://github.com/RangelReale/osin also
allow us to set expiry.

Regarding revocation, it have to be requested by Client. Legtimate
clients will request it but what about abusing clients? They will never
send revokation request.

Also as mentioned in IETF RFC6819
https://tools.ietf.org/html/rfc6819#section-5.1.5.3:
Is Limited / one-time-usage and Audience etc. implemented in fosite?

On Saturday 28 May 2016 11:26 PM, Aeneas wrote:

I agree that short lifetime is good for security but it will also
incur much load on authorization server as it has to process
frequent refresh requests. We could have clients from different
platforms (JS based web app, android app, native desktop app etc.)
with different usage and trust level. Say we have our own multiple
apps or the apps from our trusted vendors with higher trust level,
here it will be safe to issue tokens with longer expiry.

I am sorry but I have to disagree. The trust level should not be
responsible for deciding token lifespan. Tokens from can be stolen
from trusted clients and untrusted clients alike. Keeping token
lifetime short increases security. Please remember that OAuth2 is a
delegation protocol and it should be treated as such. :)

Please read the official recommendation IETF RFC6819
https://tools.ietf.org/html/rfc6819#section-5.1.5.3:

A short expiration time for tokens is a means of protection against
the following threats:

o replay

o token leak (a short expiration time will reduce impact)

o online guessing (a short expiration time will reduce the
likelihood of success)

Additionally, generating hmac tokens is cheap with fosite. The
database might get some load but I don't think that it's going to be a
real issue, even if token expiry is only an hour.

If you fear that database load might be an issue, take a look at the
Hydra Refactor https://github.com/ory-am/hydra/tree/refactor. It's
an authorization server that uses fosite and does everything in-memory.

If we save/load expiry from database then it will give us ultimate
control. You may have hundres of clients and each client has
thousands of end users, consuming your API. Some day suddenly you
found that a few clients are abusing or sending too many request.
Here if you have expiry in database then you can easily expire
there access token as well as refresh token so they have to
authenticate again.

That is what [token revokation](IETF
RFC7009](https://tools.ietf.org/html/rfc7009) is for. It's currently
not implemented in hydra but it should be very easy to add an endpoint
and remove malicious / leaked tokens from the database.

Another point I want to make is that issuing access token is not the
bottleneck, but token lookup is. You are suggesting that the expiry
time should be flexible. This does not work if you issue JWT, because
you can't change their expiry tokens.

Feel free to ask questions if things are unclear.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#45 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AKD0TSpI77Wo_rBCNMsg5rtwmCIyjzV9ks5qGIHUgaJpZM4Ie4zk.

Thanks & Regards
Sam Tech

[aeneasr]

But still having flexibility to get/set expiry will be a great feature for fosite. It is the only thing that i see as bootelneck in fosite. As we are issuing tokens but we do not have control over it.

In fosite you can invalidate tokens by simply removing them from the database. No need to tamper with expiry date :)

There we implemented that feature and we were very happy wth that. We also face few instances where few clients were poorly designed and not comsuming API as it should be, so we just expire theire token and even disabled few clients.

You can invalidate access tokens issued to abusing clients by removing them from the database.

Regarding revocation, it have to be requested by Client. Legtimate clients will request it but what about abusing clients? They will never send revokation request.

You are absolutely right, I forgot that RFC7009 is client-facing. The point I wanted to make is that you can remove tokens from the database in order to invalidate them. Playing with the expiry date does not make a lot of sense to me as the expiry date is issued once at token creation and submitted as a hint to the client. Additionally it does not work with JWT. I also think that looking up JWT sessions in a database defeats the purpose of using JWT.

Not sure but i guess OSIN https://github.com/RangelReale/osin also allow us to set expiry.

Yes, OSIN let's you save the expiry date per token in the database. OSIN however has a lot of other flaws and a poor security concept. I believe that choosing long expiry dates for access tokens is also poor security. This is why there is only one global expiry time in Fosite.

Please don't mistake me with someone who doesn't like new ideas :) I simply believe that your use cases can achieve the same functionality with better security if the expiry date is short and non-modifiable and tokens are invalidated by removing them from the database.

Let me know what you think.