Re: [Edgex-golang] [Edgex-tsc] Auth Service

Smith, Nick A <nick.a.smith@...>



My 2 cents. Whilst in totality specifications like OAuth2 are complex it is perfectly possible and sensible from a security perspective to use subsets of their functionality. To that end whilst JWTs are far from perfect they have at least been studied to ascertain their attack surface and they have widespread support. Securing JWTs can be achieved by reducing the scope of their configuration i.e. disallowing insecure algorithms (RSA PKCS1.5, None) and making some of the optional headers mandatory (key ID etc).


I’d encourage the use of something like OpenID Connect Code Flow for authenticating humans whilst going for something simple for services like an OAuth2 Client Credentials Grant. Both result in the authenticating entity receiving a token that can be used in authorization later on, both have widespread adoption, both have had at least some security analysis and are relatively simple to integrate. Additionally the use of existing protocols enables existing identity federation services to be re-used. Creating more identity and credential repositories is more likely to reduce security than to help it.


None of this takes away from Drasko’s work as it’s possible to use his API in both an OAuth2 and OpenID Connect context (as identity verification is open to implementation; it could be via a shared key, username/password or some sort of 2FA) but those standards do enable better integration into existing infrastructures.




From: edgex-golang-bounces@... [mailto:edgex-golang-bounces@...] On Behalf Of Vlado Handziski
Sent: 17 January 2018 15:26
To: Domenico Rotondi
Cc: Drasko DRASKOVIC; edgex-tsc-core@...; edgex-golang@...; manuel@...; edgex-tsc-security@...; edgex-tsc@...; Nikola Marcetic; Dejan Mijic; edgex-devel@...; Leonardo Straniero; Diego Pedone
Subject: Re: [Edgex-golang] [Edgex-tsc] [Edgex-tsc-security] Auth Service


Hi all,


I also think that this approach of using JWT as short-term, single-use authorization tokens has benefits vs. using JWT as a pseudo session mechanism. I am not a security expert, but there seems to be a lot of general debate in the community over the usability of JWT in this context, i.e.:



I definitely see value in having a lightweight AAA, as proposed by Drasko, so one option to reduce the attack / error surface would be to use something like PAST instead:






On Wed, 17 Jan 2018 at 16:02 Domenico Rotondi <domenico.rotondi@...> wrote:

On 17 Jan 2018 at 6:53, Drasko DRASKOVIC wrote:
Hi all,
if of interest, in FINCONS SpA, we have developed, in the context of EU R&D
projects, a set of libraries (JavaScript and Java) and backend to manage login and
AuthZ using JWT tokens and other security features to increase the overall system
reliability. Everything is provided with the Apache V2 license.

From an architectural point of view our scenario envisages clients, an Authorization
Service and one or more "operational services" (in our case for example a document
store and a policy store).
As in token based systems, any request to any service has to include an explicit
authorization token that must be requested to the Authorization Service before
submitting the service request (this is managed internally by our libraries). Therefore,
on the service side there is no need to check user ID, access rights, etc.; the only
check is related to the correctness of the presented token.

Of course, the client needs initially to authenticate itself, but, in order to avoid having
to manage sensitive info like password on the backend, we actually use a
proof-of-ownership of the presented identity.
If the proof is successful then the client and the Authorization Service create a shared
secret which is used afterwards to manage token's requests from the client to the
Authorization Service.

If of interest we'll be happy to provide the SW. Of course no problem in providing
further details.

Hi all,
I started writing a small Auth service that would live behind the
proxy and have 3 goals:
1) To create (register) a user (i.e. create a user account in MongoDB)
2) Login user (i.e. issue JWT token upon correct username + password)
3) Expose /auth API call so that all other API calls to other services
can be first redirected first to this service for Auth check

Basically - whole API of the service is here:

This service would solve gateway protection on production level
(encrypted user credentials are kept in MongoDB, can be also written
in Vault in later versions), and I guess that first version can be
finished in a couple of days.

Would something like this be of interest?

Best regards,
Mainflux Author and Technical Advisor   |  Industrial IoT Cloud
Engineering Division |   Paris, France

Twitter: @draskodraskovic

EdgeX-TSC-Security mailing list
Questa mail potrebbe includere materiale confidenziale, proprietario o
altrimenti privato per l'uso esclusivo del destinatario.
Se l'avete ricevuto per errore, siete pregati di contattare chi ha inviato il
messaggio e di cancellarne tutte le copie.
Ogni altro uso da parte vostra del messaggio è proibito.
Se non ti è necessario, non stampare questo documento. Grazie

This message is for the designated recipient only and may contain privileged,
proprietary, or otherwise private information. If you have received it in error,
please notify the sender immediately and delete all the copies.
Any other use of the email by you is prohibited.
Please consider the environment before printing this email

This email has been checked for viruses by AVG.

EdgeX-TSC mailing list

Join to automatically receive all group messages.