Types of authentication > By type of data accessed

In the last video, you took a look at the five scenarios which are described in the Google Earth two page, that one page that we were just seeing. You may be wondering, "They are talking about all these different things, but how exactly do I use that information?" Now before you do that, I would like to point you to this excellent website called-- I'm not sure how to pronounce this but it's D-A-I-M-T-O.com, daimto.com. It's maintained by someone called Linda Lawton and I think that this is a phenomenal website. I would just like to shout out to Linda that this website is excellent and thank her for providing this resource.

This tutorial is about open authentication. By the way, OAuth stands for open authentication. This actually talks about a different way to look at the OAuth that you will need for your particular use case. I'll actually go over to my flow chart tools soon to explain what this is. You don't want to look at the entire tutorial but while I'm here, I'll also point out this other tutorial that she has called Google three-legged OAuth 2 flow.

Once we are done with the describing the different parts of the service account and how it works and all that, as well as the- even the web server type application, I would like you to go and take a look at this post because this describes a way to do what is called the three-legged OAuth 2 flow. Which is like the very standard flow that you see and most of the scenarios where they have these web server applications talking to a Google service via OAuth. I think that this will be immensely helpful for you to understand what is going on under the hood.

Now that we have seen this, let's go back to the flow chart. This is the summary of that post. Now before 2015, and I do remember that there was a point in time when a lot of YouTube data could be accessed without any authentication whatsoever. You can just send API requests, HTTP requests, and you will get like tons of useful information back. In fact, you could even do that with just Google's search results. You can just pass some parameters about a number of results you want and which page number and so on.

There was a point in time when you could get all those results just like that without any authentication at all. In fact, a really good example of this was Google Maps where they could just access all this data, but you didn't have to create any account at Google or anything like that. It was just available to the public for free with no authentication and at some point, and I think it must have happened around 2015 or so according to that article, Google changed this system and made everything available only after some kind authentication even if it was just very basic OAuth.

Now, in this case, you can actually divide or separate the three kinds of authentication that you would need based on the type of data that you are trying to access. For example, if you are interested in just getting public data and a good example is Google Maps because Google Maps information is public information, you just need to get something called a client ID. You can do that by going into Google's console, and I think you need to create a project or something. Once you do that, you will be able to get this client ID and just use that to access Google Maps data through the API.

It's not relevant to Dialogflow because I don't think at the moment there is anything in Dialogflow which is publicly accessible in that way. Then you have the other type which is the user data. Now, this is interesting. When we talk about user data in the context of Dialogflow, what you're really talking about is some third person users Dialogflow agent and not their actual data which we collect from them and store it or associated with our Dialogflow agent.

No, this one is talking about-- In this case, the user data here refers to somebody else's Dialogflow agent which we want to get access to, to do some operations. You might be wondering, "Why would you want to do something like that?" I'll give you an example, if you want to-- I'm going to go over to my website and I have this tool called the Dialogflow Navigator. What it does it allows people to search across all the intents they have for specific keywords. As you know dialog tool doesn't provide this feature as of today which is October 2018, November, sorry 2018.

In this case, what I actually have is somewhat lame I can say because it's an offline tool. You have to download the zip file and then you will have to load it into my tool and then you can search into whatever intents it loaded and be able to spot which intent is the one which has the keyword you are looking for. That's great, but it's not connected to your agent, which means that if you went to your Dialogflow agent and then you made some changes, that will not automatically reflect in my tool. You have to go and again export the zip file and again, you have to load it into the tool and do a second search.

In this case, one way to improve the tool, and definitely something I'm thinking about, is to implement this three-legged OAuth. This is what we were just looking at on Linda's website a while back. You can implement this three-legged OAuth and what that will allow me to do is I can have a website where some dialog developer could come to my site, click on a button, it will take them to Google's website to login to their Google account and then it'll ask for permissions to access their agent and so forth.

Then once they grant the permission, it will redirect back to my website with either confirmation that they said yes or if they say no, then it will come back with some information that the user refused to give permission to my app to access their Dialogflow agent. Supposing that they did allow me access to the Dialogflow agent, what that will do is I can create all these Dialogflow Navigator features with the connected agent.

What that means is that if somebody were to search for keywords in their agent and then they go to their agent in Dialogflow, go to the console, make a few changes, they could come back to my site click on a refresh button because they are already authenticated with-- That is my app is authenticated with their Google account, that will allow me to access all the information of that agent. Which means I can pull in let's say all the intent data, which means as soon as they click on the refresh button, I have the latest version of their agent is accessible to my web application. Which means when they search at that point, it is now pulling from real-time data rather than the--

The other way of doing it was if they were using my other way of the dialog for navigator app that I have like now, they would have to go and re-export the zip file and do that every time they make changes to their agent. Here, that's what user data is referring to. You can see that when you want to get such user data, you need to implement this three-legged OAuth system, and I don't think that there is any other way to do that.

Now the other option, the other kind of data that you might be interested in is called developer data. This is where the service account style authentication is useful. Now, where will you use this? For example, if you want to build your own custom integration with your Dialogflow agent, you might want to skip the one-click integration that is already provided inside the console. You might want to build your own custom integration and that actually gives you a lot of benefits. In that case, you will use this service account technique to use the API to talk to your Dialogflow agent.

Now a good example for doing this would be-- I have on my website, I have this thing called a support bot. It's a chatbot where it is actually using Dialogflow, but you can see that it doesn't look anything like the one-click integration bot that you get in Dialogflow. You have this custom branding that I have over here. Then you can see that it has these list items. I can click on them. It will actually show me information which has these chat boxes how like images in them. Then there's a link that I can click and go and visit some other page and so on.

At the end of it, I even have this button which I can click and start over in the conversation. The idea here is to be able to do this custom website chatbot, I would have to use the custom integration, which I just mentioned. To do that, I would have to use the service account to be able to access the agent's information via REST API. Once I do that, that effectively gives me a lot of flexibility and how I render this UI and how I want my agent to behave according to whatever input that the user provided. In that case, you would use the service account. That's the other authentication. This is for when you want to get developer data.

These are the three types of OAuth that you have in Google OAuth. Having a good idea of what type of data you want to access will help you decide the specific OAuth system that you need to build out for your particular use case.