Difference between revisions of "Identity Service"
| (18 intermediate revisions by the same user not shown) | |||
| Line 5: | Line 5: | ||
== The Application == | == The Application == | ||
| − | In order to use the LFS Identity Service | + | In order to use the LFS Identity Service you must always register a so called Application. An Application is a record of your website or script that will perform LFS User authentication. |
You must have at least one Application, but it is possible to register multiple Applications used for different purposes. | You must have at least one Application, but it is possible to register multiple Applications used for different purposes. | ||
| Line 15: | Line 15: | ||
An Application must have a name and one redirect uri pointing to a callback endpoint on your website where authenticated users will return to after authentication. A redirect uri is also required even if you only use the LFS API for your own (back end) purposes. In that case you can enter a fictional redirect uri. | An Application must have a name and one redirect uri pointing to a callback endpoint on your website where authenticated users will return to after authentication. A redirect uri is also required even if you only use the LFS API for your own (back end) purposes. In that case you can enter a fictional redirect uri. | ||
| − | + | Once your Application is registered, you will receive a Client ID and a Client Secret that you must store in order to perform Identity Authentications later on. Note that the Client Secret will only be shown to you once, after Application registration. | |
== Authentication Grant Types == | == Authentication Grant Types == | ||
There are 2 authorization grant types that can be used. Which you should use depends on your use case: | There are 2 authorization grant types that can be used. Which you should use depends on your use case: | ||
| − | * '''Authorization Code Grant with Proof Key for Code Exchange (PKCE)''', | + | * '''Authorization Code Grant''', used with server-side applications or websites |
| + | * '''Authorization Code Grant with Proof Key for Code Exchange (PKCE)''', used with [https://en.wikipedia.org/wiki/Single-page_application Single Page Applications] | ||
* '''Client Credentials Grant''', used with back end scripts | * '''Client Credentials Grant''', used with back end scripts | ||
| + | === Server Side Application === | ||
| + | If you have your own server side website or application (e.g. back end driven with PHP) where you want to allow your users to login using their own LFS credentials or just confirm their LFS identity to e.g. sign them up for races, you must use this grant type. You will also have the option of accessing certain information of these LFS accounts by using [[Identity_Service#Authentication_Scopes|scopes]] during the authentication process. | ||
| + | |||
| + | For this purpose you should use the Authorization Code Grant. | ||
| + | |||
| + | How does that work? | ||
| + | |||
| + | ... stuffs here ... | ||
| + | |||
| + | === Single Page Application === | ||
| + | If you have your own javascript driven website or application where you want to allow your users to login using their own LFS credentials or just confirm their LFS identity to e.g. sign them up for races, you must use this grant type. You will also have the option of accessing certain information of these LFS accounts by using [[Identity_Service#Authentication_Scopes|scopes]] during the authentication process. | ||
| − | |||
For this purpose you should use the Authorization Code Grant with PKCE. | For this purpose you should use the Authorization Code Grant with PKCE. | ||
| Line 30: | Line 41: | ||
... stuffs here ... | ... stuffs here ... | ||
| + | |||
| + | * https://id.lfs.net/oauth2/authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=openid%20profile&state=CSRFTOKEN | ||
| + | * receive redirect URI (goes to lfs.net's login page) | ||
| + | * client logs in if not already logged in | ||
| + | * client must accept scopes requested by Application | ||
| + | * client is redirected to id.lfs.net one final time | ||
| + | * client is redirected to Application redirect URI | ||
=== Back End Scripting === | === Back End Scripting === | ||
| Line 37: | Line 55: | ||
... stuffs here ... | ... stuffs here ... | ||
| + | |||
| + | * POST to https://id.lfs.net/oauth2/access_token | ||
| + | ** grant_type => 'client_credentials', | ||
| + | ** client_id => 'CLIENT_ID', | ||
| + | ** client_secret => 'CLIENT_SECRET', | ||
| + | * receive access token immediately | ||
| + | |||
| + | == Authentication Scopes == | ||
| + | Scope information here. | ||
| + | |||
| + | == Refresh Token Flow == | ||
| + | ... stuffs here ... normally used only with the Authorization Code Grant because for the Client Credentials Grant type you can simply perform a new Access Token request. | ||
== Usage Examples == | == Usage Examples == | ||
Latest revision as of 15:53, 22 February 2022
Introduction
The LFS Identity Service -based on Oauth2- allows you to integrate LFS user authentication into your own website and / or use the LFS API. Both purposes are often used together; your website can authenticate an LFS user visiting your own website to perform actions on your website, on behalf of the LFS user. These actions are performed using the LFS API. Though you can also use the LFS API alone via (back end) scripts, to fetch and / or update information related to your own LFS account.
You can find many explanations and further details about Oauth2 on the internet. A good introduction for example is the one from Digital Ocean.
The Application
In order to use the LFS Identity Service you must always register a so called Application. An Application is a record of your website or script that will perform LFS User authentication.
You must have at least one Application, but it is possible to register multiple Applications used for different purposes.
You can register your Applications at https://www.lfs.net/account/api
An Application is always required for Oauth2 authentications, one for each grant type (or flow) you will be using.
An Application must have a name and one redirect uri pointing to a callback endpoint on your website where authenticated users will return to after authentication. A redirect uri is also required even if you only use the LFS API for your own (back end) purposes. In that case you can enter a fictional redirect uri.
Once your Application is registered, you will receive a Client ID and a Client Secret that you must store in order to perform Identity Authentications later on. Note that the Client Secret will only be shown to you once, after Application registration.
Authentication Grant Types
There are 2 authorization grant types that can be used. Which you should use depends on your use case:
- Authorization Code Grant, used with server-side applications or websites
- Authorization Code Grant with Proof Key for Code Exchange (PKCE), used with Single Page Applications
- Client Credentials Grant, used with back end scripts
Server Side Application
If you have your own server side website or application (e.g. back end driven with PHP) where you want to allow your users to login using their own LFS credentials or just confirm their LFS identity to e.g. sign them up for races, you must use this grant type. You will also have the option of accessing certain information of these LFS accounts by using scopes during the authentication process.
For this purpose you should use the Authorization Code Grant.
How does that work?
... stuffs here ...
Single Page Application
If you have your own javascript driven website or application where you want to allow your users to login using their own LFS credentials or just confirm their LFS identity to e.g. sign them up for races, you must use this grant type. You will also have the option of accessing certain information of these LFS accounts by using scopes during the authentication process.
For this purpose you should use the Authorization Code Grant with PKCE.
How does that work?
... stuffs here ...
- https://id.lfs.net/oauth2/authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=openid%20profile&state=CSRFTOKEN
- receive redirect URI (goes to lfs.net's login page)
- client logs in if not already logged in
- client must accept scopes requested by Application
- client is redirected to id.lfs.net one final time
- client is redirected to Application redirect URI
Back End Scripting
For this purpose you should use the Client Credentials Grant.
How does that work?
... stuffs here ...
- POST to https://id.lfs.net/oauth2/access_token
- grant_type => 'client_credentials',
- client_id => 'CLIENT_ID',
- client_secret => 'CLIENT_SECRET',
- receive access token immediately
Authentication Scopes
Scope information here.
Refresh Token Flow
... stuffs here ... normally used only with the Authorization Code Grant because for the Client Credentials Grant type you can simply perform a new Access Token request.
Usage Examples
examples (are these needed? Maybe the grant explanations above should be enough - I don't think I should start providing actual code examples here - there are plenty available out on the nets.)
Single Page Applications
example here
Back End Scripting
example here
