I can't find detail about authorization endpoint for this api on ssg-wsg website.
Could you provide, the url for Authorization Endpoint for the ssg-wsg API:?
Are you trying to call consent based APIs?
There is a guide here that is referencing authorization URLs for consent based APIs:
https://developer.ssg-wsg.sg/webapp/guides/6BDCEHkqNKpazwYJQfnz3l
However, for other kinds of APIs, it would seem like authorization URLs are not needed for OAuth APIs - you just need the Client Credentials for authorization.
https://developer.ssg-wsg.sg/webapp/guides/6gvz7gEnwU2dSIKPrTcXnq
It would be good if you could share more details on the issue that you are facing.
Related
It is clear how to get a token from Google(or any other OAuth provider). But I do not understand where shoud I do it - server part or client part.
For example: I have a backend on Flask with unified API for Android, iOS and web(js/react) apps.
Where do I need to get a token? On the client (Android for example) part and send it to server or in my Flask app after request from client? Where should I get data from provider? How at all works interaction between client and server while using OAuth?
Would be pleased for some explanations or links on some guides
Your UIs will manage redirecting the user to authenticate - after which the UI is given an access token to call the API with.
The OAuth provider is the entry point for authentication and issues an access token afterwards.
The API uses the access token to identify the user and authorize access to resources.
A good way to understand OAuth is the HTTP messages - my blog post highlights these, and they are largely the same for SPAs and mobile.
There are also some code samples on my blog which you can run, in case useful.
MY goal is to setup the Cognito Hosted UI to validate users after login. I have followed the steps laid out in the OAuth2 blog here: https://developer.okta.com/blog/2018/04/10/oauth-authorization-code-grant-type
My steps are as follows.
User logs into the AWS provided login screen.
It redirects to my website and I pull down the authorization code in Angular.
I send the code as part of my headers to the backend Nodejs
I use the code to get a token and then validate the token
This stream works but then what? I want to validate the AWS token for each API call but I have no idea how to access the token.
I am guessing that I am either missing the point of this procedure or that the token is somewhere I am unaware of.
Any help would be greatly appreciated.
Usually you have your own UI that redirects to Cognito to authenticate, after which the UI sends the access token to the API on every request.
All of the code samples on my Quick Start Page work like this and use Cognito.
If it helps, this is what the OAuth Technical Messages look like. Feel free to ask any follow up questions
I am trying to call some endpoints on google cloud build but I just get 401 and I am wondering how to fix this? In the end, I want to curl but if the website is not working, there is truly something wrong! Here is the picture
Only a group of API services/products on Google Cloud Platform support API keys without more authentication methods (OAuth). You can find these specific services here. In the same page that you posted, if you go down on the documentation there should be a "Authorization Scopes" section listing the required OAuth scopes that the API requires, if so, it means OAuth is needed in order to use the service.
I look at the Cloud Build Rest Api Doc and indeed I can see OAuth is required, in addition to not being listed here. You need to implement OAuth for this specific Service (Cloud Build API).
Django Oauth Toolkit docs don't describe the redirect uris, authorization grant type, or client type fields when registering your application.
The tutorial says to set client type to confidential, grant type to password, and leave uris blank.
What do the other options do?
e.g. What is client type public vs confidential? What do the grant type password, credentials, authorization, implicit do? And what are the redirect uris for?
I have found sparse information about them but no actual explanations as they pertain to django rest framework and django oauth toolkit.
You'll get answer to all your questions once you read about Oauth2 Protocol from here
But I'll try to answer your questions in brief:
I'll be using the words client and Resource Server frequently. In Oauth2 protocol, client means the system which accesses resources, data or service. (It could be your mobile app or javascript app consuming REST API's of your API Backend (or Resource Server) . If you have implemented Facebook login in your mobile/JS apps, chances are, your API backend requests Facebook for user's information. In that case your API backend is being a client and Facebook is Resource Server)
Client Types:
Client type is either confidential or public depending on whether that client can keep it's client_secret a secret. (For example, an AngularJS app cannot keep it's client_secret hidden, since anyone can do "Inspect Element" in a browser and search for it, so such a client has to be registered as public.)
Authorization Grant Types:
There are four kinds of Authorization Grant Types in Oauth2 protocol.
Authorization Code:
In this grant type, the client requests for an authorization code first, then exchanges that authorization code for an access token. It's a two step procedure. Use this if the client is an outsider (more on it in Resource-owner password based).
Implicit:
Usually used along with public client_type. Instead of a two-step procedure above, the client gets access token in one go.
Resource-owner password based:
This is used when there is a high degree of trust between client and Resource Server. This is the case between your API backend and your Mobile app. (There is high degree of trust between your API backend and Javascript app too, but since it cannot keep it's client_secret a secret, you have to use Implicit Grant type with it). Facebook or Google etc. will never give you this kind of Authorization Grant because, for them, your API backend is an outsider.
Client Credentials:
It is least commonly used. Please read about it in above mentioned document.
Redirect URI's:
Now, as far as Redirect URI's are concerned, they are needed only in Authorization Code or Implicit grant types (Not sure about Client Credentials one, somebody please enlighten me on this in comments).
Redirect URI is given so that the Resource Server knows where to send the access token. Imagine if you are implementing Facebook login. In that case you will go to developers.facebook.com and register your application (like you did with django-oauth-toolkit), while registering your application, you will specify a Redirect URI.
Specifying a Redirect URI is a way of saying. "Hey Facebook, send the access token on this URI". So if you set Redirect URI something like https://your_domain_name.com/token/facebook/, Facebook will redirect to your specified Redirect URI at the end of Oauth2 process and give Access Token in the form of GET parameter, like https://your_domain_name.com/token/facebook/?token=some_long_string&some=other_parameters.
I've already succesfully implemented LinkedIn and Twitter Oauth 2.0 authorization in my App with external libraries. But I have problems with Facebook. It seems like it has different authorization flow.
I need to have 3 endpoints to implement OAuth: request token url, access token url and authorize token url.
For LinkedIn and Twitter I have them:
REQ_TOKEN_URL="https://api.linkedin.com/uas/oauth/requestToken";
ACCESS_TOKEN_URL="https://api.linkedin.com/uas/oauth/accessToken";
AUTHORIZE_TOKEN_URL="https://api.linkedin.com/uas/oauth/authorize";
REQ_TOKEN_URL="https://api.twitter.com/oauth/request_token";
ACCESS_TOKEN_URL="https://api.twitter.com/oauth/access_token";
AUTHORIZE_TOKEN_URL="https://api.twitter.com/oauth/authorize";
But for Facebook instead of request token I have
OAUTH_FACEBOOK_DIALOG = "https://www.facebook.com/dialog/oauth";
And I'm not sure if it's equal. Probably not, since it doen's work the way it did with LinedIn and Twitter.
And in Facebook documentation they suggest to start with redirecting user to "https://www.facebook.com/dialog/oauth", but in classical OAuth 2.0 first I have to request the token from request_token_URL.
So the question is: is Facebook authorization flow actually not OAuth 2.0 and I have to use different approach?
Facebook does in fact fully support OAuth 2.0. Twitter currently does not support OAuth 2.0. LinkedIn OAuth 2.0 support I believe is still in beta. But yes, you will need to use a different approach for different versions of OAuth.