Okay, can you guys hear me?
Yeah.
Okay.
So Alona's next speaker is Milan Yackelby.
We'll describe some experience on YDC.
Here's some real use cases, right?
Yeah.
So, first of all, I'm really sorry for my French accent.
I will do my best.
Okay.
So, the point is, so I work for like a trio for years on kick-look and the WSU2.
And with the real issues and the understanding of the lighting protocols and stuff like that.
So, it's kind of an eventorist of the possibilities offered by the protocols.
This is the idea of all ID.
So, there is no specific demos.
I will explain in this as much as the time let me do what you can do with the OS2 and open ID connect.
Okay.
So, our pronunciation statement is very basic.
So, our user wants to access this bank account to a management console.
And you want to see to also display data from any kind of an older bank account data.
So, also do so.
But, the bank applications will delegate this authorization and authentication to specialize the authorization server.
Very basic.
And to do so, they will rely on a bus or reader OS2 and open ID connect.
So, I want to go to deep on what are specific,
on open ID connect or OS2.
But, basically, it's based on a challenging design,
sign the JSON object, Jots, and rely on a rest-a-a-a-a-a-a.
So, above the concept, in a study there is a force rules.
There is the resource owner, which is the end user.
There is the authorization server.
As you can see, there is the client's application that wants to retrieve data in the name of the end user.
And finally, the resource server, the server, which actually hosts the data of client's own to access.
So, please note that in open ID connect, there is no concept as a client's resource server.
But, it's managed.
I'm sorry.
In to what you call the relaying party.
And very large overview will be that the resource owner, through the client's,
as far as you can, the authorization server delivers the token that will be then used by the client
who access the resources, hosting the resource server.
Very basic.
So, before talking about authorization flows, the word about registration and token validation.
So, the registration can be there manual.
So, through the authorization, there is a operator behind the authorization server,
that will register client and deliver the client ID or any method that has the client's need.
And it can be, as well, it can be dynamic.
The client's registration itself through a specific endpoint.
And the token validation can be there local or remote.
There is a specific endpoint.
And the client's answer can submit tokens to validate and ensure that there are valid.
It is valid.
So, when we are talking about tokens, we are talking about juts.
I don't know if I have really to detail it.
So, basically sign a JSON object with a footer including his foot prints.
And when we are talking about tokens, there are four kinds of tokens.
So, there is access token, which is basically a very short time-lived token
that enables the client to access a resource server in the name of the user.
And there is the Refresh token, which is used to retrieve new access tokens without
triggering the world scenario.
So, I will go further later.
And open IDConnect, basically, the new tokens, the ID tokens, which is carrying standard days
the identity data about the user and the user info, which is none standard days.
So, that is the difference, basically.
So, you can ask by default, you get the ID token.
And eventually, you can ask for user info, which is basically a dump about what the client
has the right to know about the user.
So, when we are talking about what contains the tokens, it is defined by the concept called
Scopes.
So, U.S. for given scope.
And the authorization server configure what does this scope include,
as in terms of claims in the tokens.
So, very basic.
So, it is the core of my talks.
Basically, we are talking about token.
The authorization server delivering tokens and stuff like that.
But the question is, all the, on which conditions, the authorization server delivers
the tokens to the client or any relaying parties that wants to access data in the name of the user.
So, it is called the authorization flow.
And there is many conditions.
And many, it is very modular.
And it determines the ways that the client and the authorization server establish trust between each other.
So, the very basic, the original one, the most used is the authorization code flow.
I guess anyone that used those two must know this one.
Basically, it is all, I would like, I would say, I don't know,
85% of the clients are registered.
It is using the authorization code flow.
So, basically, the scenario is that the authorization server tries to access data through the client.
It is getting redirected to an authorization at point.
It authenticated against the authorization server.
The authorization server has several authentication,
which can reduce the user back to the client with an authorization code in the HTTP errors.
And the authorization code can be used by the client to retrieve tokens in the name of the end user.
And what is important is that adding the layer of authorization code avoids the tokens to pass through the browser.
So, it is a server to serve her exchange.
And, basically, open IDConnect is just adding an ID token,
and the user affluent points.
So, the ID token is returned the same way that access token and refresh the client's return.
So, that is open IDConnect.
So, a technical point of view, not much differences.
So, add a large scope.
We have access, it is basically, so, as client, you would use a mode of open IDC.
I don't know if you know this, but it is an appax to module.
That acts as a open IDC client are used to play on, whatever you want.
You will run dumb web app, would be the resource server.
And, basically, the user would go through the mode of open IDC,
which would act as a client, and would gather the access tokens and trigger the register exchange
in the name of the web app, which is behind it.
And, please note that you can, eventually,
about authentication, the authentication.
It is not necessarily based on the authorization server database,
but can rely on a back-office LWP directory, or an external LWP provider,
such as GitHub or whatever you want to share.
And, the authorization server can retrieve data from those,
and include it in the tokens.
So, the issue is that when using native apps such as SPA,
or mobile native apps, there is a well-known security issue.
So, basically, you can enter set the authorization code.
So, a malicious app could retrieve the authorization code at the same time of the client,
and use it to retrieve tokens in the name of the user,
and corrupt data or in the singular answer.
So, the authorization code is an in-earth flow as an extended with PICC,
for proof-of-key exchange.
So, instead of only delivering a authorization code,
instead of the client of only rejecting the user,
and through the generated code identifier and a code challenge,
we'll submit a code challenge during the redirecting,
and when asking for tokens,
it will prove that it is the same that the one we're redirected
by forwarding the code identifier so you can ensure that that is the same client
that redirected the user and that is asking for tokens.
So, you are implementing, you are mitigating the risk of an authorization code flow steal.
So, another security issue on the following layer
is that the token can be intercepted itself,
and there is more complex aditions to prevent this.
So, one of them being the MCLS flow,
in which the access token is bound to the SSL layer.
So, firstly, it is mutual TLS.
So, the client's verified server and the server's verified clients.
This way, the client's certificate is included in the tokens,
and when the client's and the resource server does the MCLS,
the resource server can ensure that the client's certificate is the same
as the one included in the tokens.
So, you can ensure that the client's is the same that has asked for tokens
and that submits the tokens.
So, I want to talk about DIPOC because, which is another variant,
because there was a digital, there is so there about it.
But the idea is that it is not bound anymore to the SSL layer
and there is a certificate used specifically for us to,
that is the more unign to know about it.
So, those are the basics.
Those are the very basics, and there is so much density to this.
So, I don't have time to talk about everything and to go into details,
about everything, but I will try to give you a panel of the possibilities
and a blade by those.
The device flow was to address the IoT world
and was specifically sought for devices without keyboards.
So, you can not direct and you can not type any kind of credentials
on your device.
So, the device here is the client's.
For example, you can imagine that you have connectivity
or anything and you want to retrieve your resource scenario
from a web database or anything like that.
In this scenario, at a very less-scale view,
the idea is that the device, when trying to access resources,
will display the way it can do,
because it can be used by the camera or the blackouts,
sometimes the device display can be,
really tough to see, and will display what is called
an user code and a verification you are in, you are in.
But the verification you are in,
is entered by the end user on another device,
such as this phone or laptop,
and the end user code and the black being done
the device can now ask for the client
to concentrate the content and the device can retrieve
access token in the name of the end user.
That's the idea.
So, this is the way, when this is the initiated by the device,
and Siba, so for client's initiative,
the black channel authorization,
is the riverway.
So, in this scenario, the user,
it's very like a free DS, so when you pay,
you get a push notification on your smartphone
to validate payment or anything like that.
So, in this scenario,
a user would be with a try to pay something
on a linear e-commerce site, such as Amazon or whatever you want,
through payment API as a thing as a resource server,
and in this scenario, the MercantWadbap
will then notify the authorization server,
which will send a pre-registered device,
a push notification,
the user would consent, and then the access token
will retrieve the load.
So, there is three modes,
I only have time to talk about the ping mode.
So, the button pull and pull are more or less the same.
So, there is a dedicated endpoint,
specified in points,
called Siba endpoint, I think that it is only
Siba and kicker car, whatever.
So, when rejecting the user,
so I squeeze some part because the core of the staff is here.
So, when the client is asked for,
for allowing any operation,
you would send the Siba endpoint,
the authorization request,
and a call back to RIA,
when the consent has been granted on the device,
the authorization server,
notifies the call back to RIA,
that the client can now retrieve
the token in the name of the user.
So, and overall,
that's exactly 3DS works,
even though it's not the same protocol,
that's exactly what it does work.
So, when under use case,
that needs to be addressed,
the meaning of two is that
the scope mechanism left a part.
There is no, there is not,
no really fine-grain authorization details,
possible using pure orst,
so it has been extended quite recently
with what is called
re-trotorization requests.
So, you have a design object describing
the operation, the client wants to do
in the name of the user,
and it will submit it to the authorization server,
the authorization server,
that the client eventually
evaluates through any given policy.
So, I will describe the mechanism.
So, in the pure
re-trotorization request workflow,
basically, the design object that I showed you,
is forwarded through HTTP errors
at the same time the user is
redirected to authorization.
So, you can imagine that it makes
a very big error.
And then the policy is evaluated
before granting the client the right
to retrieve access to the client's name of the client.
And the token's carries itself
the authorization details,
so the resource server can eventually
evaluate another policy,
possibly the same.
So, I explained
a third-party policy in the gene,
because in my experience,
you are really used
the native policy in
your authorization server,
and you define your
access policies,
an given component,
such as a document,
or OPA, or anything like that.
So, as I said,
since the authorization
details are forwarded
in HTTP errors,
disposes,
with the resource,
with the
Compatibility,
and there is a privacy
and security issues,
because there is a
I mean,
I mean, I should remove
the authorization details
are in clear.
So, here comes the push
authorization requests,
in which the client
will firstly push
the authorization details
on the given endpoints,
will be returned
and you are high,
and when asking
when redirecting the user
will refer to the
authorization server,
can bind the authorization request
with the authorization details
that were pre-pushed.
Yeah.
And finally,
so,
there are a lot of
slides about you,
but it's a
quite fast.
So, I can
maybe talk more in detail
about it.
But, yeah,
so,
OSTU is always
an open entity,
finally,
is always about
giving the right
to relaying parties
to acts
in the name of the
resource owner.
And,
you might as a
new paradigm,
so,
is the idea that
it will give
the access to a
requesting party
to the
resource owner's data.
And,
it goes with a
very complex protocol,
but the idea
that, instead of
your user
trying to access data
from two web apps,
from a single one,
there will be another
user
that can access
your users
data.
And it does
rely on
OSTU
through a mechanism
of permission
tickets and
some specific
sent points.
And, as much
as I know,
it has been implemented
in T-Clock.
And,
it is present
as well,
on the
AWS
OSTU.
So,
and,
but,
it will need
the business
that it does exist.
Yeah.
So,
and,
if you have any
questions,
are you,
feel free to do so?
Thank you very much.
Any questions?
We haven't finished here.
Yeah.
I'm sorry.
I can't show any thing!
Or I can't show anyhost in the
thing.
I can't show anyhost in there.
You're weighing
...
Sure, I'm sorry.
It's just
quite,
eight months out of this information
...
really good.
The
B-M-T stock
B-R-R M-T stock
B-M-T stock
We have ten minutes before the next stop starts.