Sam

Morning guys

Please don't say I shouldn't make my own end points... otherwise I'd be writing 0 code haha

OK so the idea is... use an oauth server for authentication... then just protect my own endpoints using their decorators i guess?

Sold guys. Sold

OK this looks very good docs.authlib.org/en/latest/flask/oauth2.html.

I'm not building my own algorithms if this is what you mean.

My own Crypto?

ATM its just a project... if i were to release it, I'd switch the auth module to OAuth or similar.

Yeah I take your advice

This guy has a similar imp to mine github.com/karec/cookiecutter-flask-restful

lol

Tom you need to let me spread my wings.

It will be called samAuth

I shall construct my own

Django is too bulky.

I've seen many implementations with flask-jwt-extended so hopefully I'll be able to stick in on code review to get some feedback on my implementation.

Meh - I don't want to use Django. Doesn't fit my needs.

I know :P

lol

Nope, not an insult

@J.J Cut down and turned into an A4 booklet I believe.

Maybe once I'm done I'll offer money on a Reddit post for users to issue a security report :P

I'm going to stick with my own imp for the time being.

Damn. OAuth costs!

So you advice I use oauth?

Also, aren't there ways you can test the security of your website? I'm pretty sure I seen a web service which grades your site against a number of different attacks.

It's more fun to implement it myself. When going into production, I will consider switching. It shouldn't be too difficult to switch the auth module anyways. Plus its good to learnn

I'm using flask-jwt-extended.readthedocs.io/en/latest to do all the heavy pulling.

I mean, I'm only making my own end points.. I'm still using a JWT library.

But that's no fun!

I guess my implementation is kinda the same

> The API first validates the application credentials and then verifies whether the token was issued to the application making the revocation request. If this validation fails, the request is refused and the application is informed of the error. Next, the API invalidates the token.

I'm reading through the docs now.

Ah wait... I think it might

Not entirely.

@TomK. I've seen oath.. they probably do something similar. But I don't really want to use it. Seems quite heavy.

Hello btw o/

I've asked a question if any of you people are knowledgeable in the area security.stackexchange.com/questions/194774/…;.

Hashing and persisting the refresh tokens using my applications secret key

@BenoitEsnard I figured out how to properly secure the token.

Also, in my logout endpoint, should I blacklist both access and refresh tokens @BenoitEsnard?

I still feel I should have some additional layer.. like a user refresh token storage

@BenoitEsnard Famous last words :p

So how would one ensure against this?

OK but suppose the attacker obtains the refresh token and it hasn't been revoked. There is no logic to say revoke this token as we do not know its been compromised

Thats where I think storing the refresh tokens along with the user would come in handy

@BenoitEsnard Yeah exactly

In what instances would a refresh token be revoked?

by using the above model, if an attacker gets hold of a refresh token, they'd also need to be logged in as the user who the refresh token belongs to

Yeh?