You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was interested in your implementation, and as far I do get it right. The implementation of this repo only covers the resource authorization but not the actual authorization service.
Currently I'm generating JWT tokens using a gin-jwt service. I'm using basic authentication to validate and generate a token, afterwards I'm using that token in Swagger API's to fetch resources.
Now I would like to use this implementation (well done btw), to leverage a more fine-grained access control using scope. I'm just wonderin where to start. I believe an UI would required to generate new apps (redirect_uri, client id, client secret, name). Afterwards that information can be used to fetch an authorization token and afterwards the access token. Once you have the latter, you can use your implementation to limit request to it's received scoped token.
I'm just wondering what would be the best way to implement the authorization behaviour, or what implementation should be used.
Thanks for everything!
Cedric
The text was updated successfully, but these errors were encountered:
@cedricve you would need an infrastructure or provider that is the authorization server that given a clientID and clientSecret will return JWT tokens. The token would be validated by this middleware handler. There are implementations for Github and Google IDP and our own, but I am also happy to review PRs for other implementations.
Some people tried to use UI logins via GH/Google and there seems to be an issue with sessions #66. If you need this and are able to fix it I am happy to review, merge and publish a release. I don't have time to fix the session issue, in my tests it worked, but I have limited time to check it, right now.
great thanks for helping, well we have our own service for authentication (username, password) -> (24h JWT). I'm looking to enhance capabilities (security) by introducing an OAuth layer on top. I will try to bake something during the weekend, and get back!
Hello zalando team,
I was interested in your implementation, and as far I do get it right. The implementation of this repo only covers the resource authorization but not the actual authorization service.
Currently I'm generating JWT tokens using a gin-jwt service. I'm using basic authentication to validate and generate a token, afterwards I'm using that token in Swagger API's to fetch resources.
Now I would like to use this implementation (well done btw), to leverage a more fine-grained access control using scope. I'm just wonderin where to start. I believe an UI would required to generate new apps (redirect_uri, client id, client secret, name). Afterwards that information can be used to fetch an authorization token and afterwards the access token. Once you have the latter, you can use your implementation to limit request to it's received scoped token.
I'm just wondering what would be the best way to implement the authorization behaviour, or what implementation should be used.
Thanks for everything!
Cedric
The text was updated successfully, but these errors were encountered: