API Authentication Without Password

[API Dev]

Is there a standard authentication mechanism/protocol by which REST api's could be accessed without the need of user password. The resource system could be configured with a trusted app. The api calls coming from this app should be assumed to be trusted (i.e. already authenticated) and they should respond back with the correct api response for the requested user. Below is the use case that I am trying to address -

We have a chatbot built using botpress platform. It is exposed to users through microsoft teams. Through the teams integration assuming we get to know the username that is interacting with the bot, we want to make an api call for this user using his username to fetch the information of this user like his paid leaves, expense reports etc (imagine an HR service kind of chatbot). When making the api call we don't have the user password for api authentication. Hence I am trying to understand if there is a standard around this. 

Thanks.

[soumya pm]

There is oauth aunthentication mechanism we can use for this purpose. It’s a token based authentication.

Thanks! 

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/api-craft/db7fc797-03da-4b62-9017-f5c054e59dff%40googlegroups.com.

--

Regards,
Soumya P M

[API Dev]

Yes but OAuth would mean two steps

1. The user would have to generate the token before interacting with the bot - not a good user experience

2. The user would have to share his token to the bot - which is kind of similar to sharing his password. Again not ideal

On Thursday, October 31, 2019 at 6:51:29 PM UTC+5:30, soumya pm wrote:

There is oauth aunthentication mechanism we can use for this purpose. It’s a token based authentication.

Thanks! 

On Thu, 31 Oct 2019 at 9:18 PM, API Dev <ami...@gmail.com> wrote:

Is there a standard authentication mechanism/protocol by which REST api's could be accessed without the need of user password. The resource system could be configured with a trusted app. The api calls coming from this app should be assumed to be trusted (i.e. already authenticated) and they should respond back with the correct api response for the requested user. Below is the use case that I am trying to address -

We have a chatbot built using botpress platform. It is exposed to users through microsoft teams. Through the teams integration assuming we get to know the username that is interacting with the bot, we want to make an api call for this user using his username to fetch the information of this user like his paid leaves, expense reports etc (imagine an HR service kind of chatbot). When making the api call we don't have the user password for api authentication. Hence I am trying to understand if there is a standard around this. 

Thanks.

--
You received this message because you are subscribed to the Google Groups "API Craft" group.

To unsubscribe from this group and stop receiving emails from it, send an email to api-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/api-craft/db7fc797-03da-4b62-9017-f5c054e59dff%40googlegroups.com.

[Eric Johnson]

There's no magic here. By some means, the client has to provide information to the server such that the server can decide what the client can see in a response.

• Transport level identification - a bunch of tactics:
• if TLS is in use, use TLS client side verification
• IP-address based validation
• Dedicated or secure networking
• HTTP-layer authentication:
• WWW-Authenticate headers (Kerberos, Basic, Digest)
• Session tokens (after, say, HTTP form-based authentication)
• OAuth
• SAML
• Application-layer authentication, such as SOAP messages that encrypt the payload

On Thursday, October 31, 2019 at 6:28:50 AM UTC-7, API Dev wrote:

Yes but OAuth would mean two steps

1. The user would have to generate the token before interacting with the bot - not a good user experience

There's a security issue you're skipping over here. The user needs the opportunity to tell the appropriate system that it is allowing some other service to do something on their behalf. Not asking that question eventually leads to a bad user experience - when the user's data is compromised.

 

2. The user would have to share his token to the bot - which is kind of similar to sharing his password. Again not ideal

Not really. OAuth tokens typically have a specific scope - for example, read only access to a specific part of an API. The tokens are also time-limited, and bound to the details of the client. Obtaining an OAuth token is generally going to be useless to an attacker, because they probably won't have the details of the specific client session necessary to use the token for an attack.

[API Dev]

I agree but I am trying to understand how are chatbots being designed for the use case I mention in the earlier post. How can develop the github chatbot for user specific commands like - "how many commits did I make last month" or "how many issues are assigned to me for project X". 

The approach of making the bot ask the user for his/her password or access token has security issues in addition to giving a bad user experience.

[Jørn Wildt]

Here is one solution, I could see working in our environment - using Single Sign On.

So, first time the user interacts with the chatbot, (s)he is redirected to a local SSO endpoint which would recognize the user automatically based on her/his Windows AD login. From there the SSO endpoint would do the OpenID Connect (OAuth2) dance which in the end would give the chatbot a trusted token containing details about the current user.

All the user experiences is a quick, almost invisible, redirect back and forth, and then the chatbot would have a suitable access/ID token representing the user.

Have fun,

Jørn

To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/api-craft/1cb78a62-9ba4-451c-89bc-a8517d1be70f%40googlegroups.com.

--

/Jørn

[sune jakobsson]

Some sites also ask for your phone number and sends you a SMS with a code to enter, and hence you know who it is.

Sune

To view this discussion on the web visit https://groups.google.com/d/msgid/api-craft/CALh-ykKCBujMArpNmTQJ%2Ba41YFWasP3Qq3iunMm8Pie1gAb%3DGA%40mail.gmail.com.

[API Dev]

Thanks for the inputs

@Sune - Yes I have such bots that request for your phone number. In the use case that I am referring to - we already know the user and he is already authenticated view microsoft teams. So another authentication shouldn't ideally be done.

@Jorn - If I understand your suggestion correctly, your solution requires the bot to ask the user to click on a "button" that initiates the SSO + OpenID connect sequence. 

1. Do we need this to identify the username? If so, we already know this through microsoft teams. The user is already authenticated by teams and microsoft passes that information to the chatbot platform.

2. If you meant a user click on a button is required, I didn't quite catch why do we need user intervention (button click) when he is not going to enter his credentials at any step.

3. This sequence if required would be needed every time the access token expires. Is that correct?

Thanks.

On Friday, November 1, 2019 at 2:40:27 PM UTC+5:30, sune wrote:

Some sites also ask for your phone number and sends you a SMS with a code to enter, and hence you know who it is.

Sune

On Fri, 1 Nov 2019 at 09:09, Jørn Wildt <j...@elfisk.dk> wrote:

Here is one solution, I could see working in our environment - using Single Sign On.

So, first time the user interacts with the chatbot, (s)he is redirected to a local SSO endpoint which would recognize the user automatically based on her/his Windows AD login. From there the SSO endpoint would do the OpenID Connect (OAuth2) dance which in the end would give the chatbot a trusted token containing details about the current user.

All the user experiences is a quick, almost invisible, redirect back and forth, and then the chatbot would have a suitable access/ID token representing the user.

Have fun,

Jørn

To view this discussion on the web visit https://groups.google.com/d/msgid/api-craft/1cb78a62-9ba4-451c-89bc-a8517d1be70f%40googlegroups.com.

--

/Jørn

--
You received this message because you are subscribed to the Google Groups "API Craft" group.

To unsubscribe from this group and stop receiving emails from it, send an email to api-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/api-craft/CALh-ykKCBujMArpNmTQJ%2Ba41YFWasP3Qq3iunMm8Pie1gAb%3DGA%40mail.gmail.com.

[Jørn Wildt]

Oh, this gets a bit too complex very fast, so don’t expect too much.

1. If you already are authenticated by Microsoft Teams and have the user info from there then I basically don’t understand your question, sorry.

2. The chatbot could store the token in it’s session - if it is there, use it, if not, then redirect the user to the authentication. No button needed.

3. Yes. The chatbot needs refresh the token once in a while. Some system returns both a short lived IDToken and a long lived re-authentication token (I cannot remember the right name for that).

/Jørn

To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/api-craft/dc21f4c0-5616-46a7-9b23-e694394e305a%40googlegroups.com.

--

/Jørn